From Sensor Networks to Concurrent Systems

Ciprian Teodorov, Damien Picard and Bernard Pottier

Université 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 al-
gorithms, 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 sys-
tem 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 attrac-
tive 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 in-
formation.

We have found this natural decomposition helpful to build development environ-

ment 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 comput-

ing 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 de-
scription from process behaviour description, enabling heterogeneous behaviour com-
position. An intermediate Control Data Flow Graph (CDFG) format supports algorithm
expressions from different development languages and paradigms, including communi-
cating processes. The multi-level simulation capabilities of the environment helps the
designers to easily spot the eventual problems and help them understand subtle char-
acteristics 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 coop-
eration 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) tech-
nology, wireless communication and digital electronics have enabled the development
of tiny, low-cost, low-power, networked sensors. These tiny sensors, collaborating to-
gether, offer numerous advantages over traditional networks, such as large-scale flexible
architecture, high-quality of sensed data, application adaptative mechanisms. The wire-
less 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 pre-
determined 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 wire-
less 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 num-
ber 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 ex-
ternal 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 appli-
cation as they are cheap, disposable, easy to deploy, self-organising, fault-tolerant.
Some of the application are: monitoring friendly forces, battlefield surveillance, re-
connaissance 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 en-
vironmental conditions that affect crops and livestock; irrigation; chemical/biolog-
ical detection, forest fire detection; flood detection (i.e. ALERT system[36]).
– Health. Some health application for sensor networks are integrated patient monitor-
ing; drug administration in hospitals, tracking and monitoring doctors and patients
inside a hospital.
– Home. Coupling sensor nodes with actuators inside home appliances, such as vac-
uum 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 key-
boards; 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: scala-
bility, fault tolerance, production price for a sensor node, hardware constraints, sensor
network topology, environment, transmission media, power consumption, network dy-
namics. 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 gener-
ated 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 net-
works.

Topology. Sheer number of inaccessible and unattended sensor nodes, which are prone
to frequent failures, make topology maintenance a challenging task[2]. Coping with fre-
quent topology changes and very hard power consumption constraints requires special
routing protocols.

Environment. Sensor nodes are deployed very close or inside the monitored phe-
nomenon. 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 medi-
ums 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 compu-
tations 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 de-
ployed 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 infrastruc-
ture 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 net-
working 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 rout-
ing 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 sen-
sor 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 strin-
gent requirements regarding scalability, energy efficiency and other factors presented
before require new solutions.
 Routing Protocols in WSN

Network Structure Protocol Operation

Flat Hierarchical Location Negotiation Multi-Path Query QoS Coherent

Networks Networks Based Based Based Based Based Based
Routing Routing Routing Routing Routing Routing Routing Routing

[37, 35, 41, 87] [34, 55, 78, 48]

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

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

According to [5] routing protocols in WSNs can be divided, depending on the net-
work structure, into: Flat Protocols, Hierarchical Protocols, and Location-based Proto-
cols. According to the protocol operation they can be classified into: Negotiation Based
Routing, Multi-Path Based Routing, Query Based Routing, and Coherent Based Rout-
ing. 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 character-
istic (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 control-
lable 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 en-
hancements and optimisations. In the paper already cited the authors presented STCP
protocol, a generic, scalable and reliable protocol for sensor networks which imple-
ments 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 Re-
liable 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 develop-
ment 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 coordi-
nates 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: pro-
gramming support and programming abstractions (see Figure 5). Programming support
class is concerned with providing systems, services and runtime mechanisms such as re-
liable 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 appli-
cation 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 in-
jected, 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 in-
structions introduce. The Maté[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 spread-
sheet 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 pro-
grammers to finely tune the network on the basis of application requirements, thus pro-
viding 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, nat-
urally, 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 sen-

sor 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 au-
tomatically 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 ver-
ification 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 frame-
works 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 verifica-
tion 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, communi-
cation 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 fea-
tures 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 sys-
tems. 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 con-
tention 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 char-
acteristics 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 devel-
opment 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 com-
position 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] pro-
tocol 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 net-
work architectures. To validate a network architecture, the presented approach is taking
in account two proof techniques: formal validation and simulation. The formal valida-
tion 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 Behaviours
(Avel) (SyNe)

Avel object Object model SyNe object

model builder model

Object model
Connectivity + Behaviours

CDFG model CDFG builder

Complete CDFG
Scheduling

Code generator Simulator Synthesis tools

OCCAM Program Chronograms

Execution Execution trace

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 be-
haviour), 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 pro-
gramming language. At the moment the framework uses only the synchronous commu-
nication 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 be-
haviour specification, then we will present the process architecture model. Starting from
this internal representation we will show how the target code/architecture gets gener-
ated. 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 inter-
mediate 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 simu-
lator 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 Net-
workExample1 here. At the first level of hierarchy the system is composed of five pro-
cesses: 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 de-
scription. 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 ad-
vantage 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 compu-
tation 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 descrip-

tion. 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 descrip-
tion used in the synchronous network model[53]. This model is used because it is a sim-
ple 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 con-
junction 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 for-
mally 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 ele-
ments 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 in-
nbrs ) of elements of M ∪ null to statesi , in-nbrs represents the incoming neigh-
bours 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 } [ Leader ( 5 ) ]
P r o c 2 { Proc3@1 } [ Leader ( 1 ) ]
P r o c 3 { Proc4@1 } [ Leader ( 2 ) ]
P r o c 4 { Proc1@1 } [ 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 anal-
ysed, tested or compiled to target architectures. Firstly the CDFG model is briefly pre-
sented in the next section, and, afterward, a CDFG simulator is presented. We devel-
oped 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, func-
tion 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 synchro-
nisation, this is implemented via processes communicating via channels (CSP like
formalism): sendNode and ReceiveNode.
– Computation operation: to cope with the computations performed by the applica-
tion: 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 Pro-
cess Node n. They each hold a finite loop represented by the hierarchical nodes Fixed-
LoopNode 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 communi-
cation 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
 System

Process_Node_2

right
left1 Ports
Memory MemoryINT

left leader send id

right1

Memory Memory Memory Memory INT Memory INT Memory

SequentialNode
idIn Local memories (variables)
INT Memory Memory Memory Memory INT Memory Memory INT Memory

WhileLoopNode
SequentialNode
true Memory

Memory Memory INT Memory Memory Memory Memory Memory INT Memory
INT

SequentialNode
1 false 1

INT BOOL Memory INT INT Memory Memory Memory Memory Memory INT INT
Memory

SequentialNode ParallelNode_66
WriteMemoryNode_39 WriteMemoryNode_43

BOOL INT Memory Memory INT Memory Memory Memory INT Memory
SequentialNode

SequentialNode SequentialNode
ParallelNode_71 ParallelNode_82
1 1
Initialisations
Memory Memory INT Memory INT Memory Memory INT Memory Memory INT Memory
SequentialNode
SequentialNode
LoadMemory_Node_126 1 LoadMemory_Node_105 1

Memory Memory INT INT INT Memory Memory INT INT Memory Memory INT

LoadMemory_Node_77 ReceiveNode_Node_88_left1 1

Memory Memory INT INT INT Memory Memory INT INT Memory INT INT

-1 WriteMemoryNode_107 SendNode_Node_79_right1 WriteMemoryNode_89

Memory Memory Memory INT INT INT INT INT INT

TestNode

Memory Memory Memory Memory INT INT INT INT INT

SequentialNode SequentialNode
1 -1 Communications
Memory Memory Memory Memory INT INT INT INT INT Memory

WriteMemoryNode_118

Memory Memory Memory Memory INT INT INT INT INT

TestNode TestNode
INT ~=

Memory Memory INT Memory Memory INT BOOL

SequentialNode SequentialNode
SequentialNode SequentialNode
1 1

Memory INT INT Memory INT Memory INT Memory INT

Message generation function
1 LoadMemory_Node_157 true 1 LoadMemory_Node_183

Memory INT INT INT INT BOOL Memory INT INT INT

WriteMemoryNode_167 WriteMemoryNode_192

INT INT INT BOOL INT INT

> =

BOOL BOOL

Merge_Node_171 Merge_Node_197

INT BOOL

INT BOOL

Merge_Node_202

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

INT

State transition function

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 gen-
erated 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 en-
gineering 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 inter-
preter 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 han-
dling 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 ex-
ample 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 synchro-
nisations. The communications between the send and receives nodes are effectively
performed by the use of channels implemented as simulation objects. That is, the chan-
nel 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 instruc-
tions are described above). These nodes are hierarchical and imposed static synchro-
nisations to their sub-operators unlike the channels of communication which induced
dynamic synchronisations. The interpreter defines two different behaviours for the se-
quential 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 simultane-
ously 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 mes-
sage 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 syn-
thesis and behaviour synthesis. The first one deals with the emission of the code rep-
resenting 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 pre-
sented 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

Topology generator Sensor network

model

Topology Behaviours
(Avel) (SyNe)

Avel object Object model SyNe object

model builder model

Object model
Topology viewer
Connectivity + Behaviours

CDFG model CDFG builder

Complete CDFG
Scheduling

Code generator Simulator Synthesis tools

Trace viewer
OCCAM Program Chronograms
Execution Execution trace
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 dis-

tributed applications as a set of communicating processes. A generic retargetable back-
end 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, num-
ber 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 net-
work 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 sys-
tem 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 sat-
isfaction, 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 pre-
sented 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 frame-
work 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 topol-
ogy from local behaviours. This separation is based on a simple model binding pro-
cesses together and binding processes to their behaviour. This mechanism enables sim-
ulation 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 be-
haviours.

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 Communi-
cations, 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 Inter-
national 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 Pro-
gram (ATIRP2000), 2000.
13. B. Chen, K. Jamieson, H. Balakrishnan, and R. Morris. SPAN: an Energy-efficient Coordina-
tion 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 Commu-
nications, 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-and-
Respond 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 Interna-
tional 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 Auto-
matic 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 Dis-
tributed 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 Mul-
tipath 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. Schoell-
hammer. 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 Dis-
semination in Wireless Sensor Networks. Proc. 5th ACM/IEEE Mobicom Conference (Mo-
biCom ’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 Net-
works. 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 Mo-
bile Computing and Networking, pages 267–278, 2003.
41. J. Kulik, W. Heinzelman, and H. Balakrishnan. Negotiation-Based Protocols for Dissemina-
tion Information in Wireless Sensor Networks. Wireless Networks, 8:169–185, 2002.
42. Philip Levis and David Culler. Maté: A Tiny Virtual Machine for Sensor Networks. Pro-
ceedings 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 Inter-
national 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 Program-
ming (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 Comput-
ing 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 Net-
works. 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 Net-
work 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 Hetero-
geneous 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 Network-
ing 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 Pro-
ceedings of the Second ACM Conference on Embedded Networked Sensor Systems (Sen-
Sys’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. Proceed-
ings of SNPA, Achorage, Alaska, 2003.
76. I. Stojmenovic and X. Lin. GEDIR: Loop-Free Location Based Routing in Wireless Net-
works. 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 Wire-
less 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 Net-
works. Proceedings of the ACM MobiCom ’01, Rome, pages 221–235, 2001.
86. Y. Xu, J. Heidemann, and D. Estrin. Geographicaly-informed Energy Conservation for Ad-
hoc 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 Dissemi-
nation 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 Recur-
sive 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 Sum-
mit, Las Vegas, NV, 2001.