wireless sensor network to satellite interface
TRANSCRIPT
Wireless Sensor Network to SatelliteInterface.Master thesis in Information and Communication Technology
NGUYEN HUU VAN LONG
Department of Information & Communication TechnologyUniversity of Science and Technology of HanoiIntake 2012-2014
Supervisor: Professor Bernard PottierUniversity of Bretagne OccidentaleLab-STICC, CNRS, UMR 6285
Tutor: Professor Olivier RuattaUniversity of LimogesDMI-XLIM UMR 7252
Abstract
This is the report describing works in the research topic: Wireless Sensor Network to Satellite
Interface during the 5 months internship at Lab-STICC, CNRS, UMR 6285, University of Bretagne
Occidentale.
Wireless Sensor Network (WSN) currently is a solution for many practical problems in emer-
gency and environment controlling. Obviously, WSN is deployed in many regions and works effec-
tively to monitor weather conditions or to predict, prevent the effects of environment. According
to the development of space technologies, especially in satellite technology, i.e pico satellite (Cube-
Sat), there are several opportunities in cooperation between satellite and WSN to control remotely
the distant WSN, i.e ocean, desert. Therefore, it is very important to develop and experiment in
simulation level to explore the potentials and reduce the risks for the data communication between
satellite and isolated WSN.
During the internship, we focus into building network toplogy, modeling the interaction between
satellite and WSNs, developing several protocol algorithms and experiment at simulation level.
There are five chapters are presented respectively in this report.
Chapter 1 - Introduction presents the context of internship work as well as the motivation and
objective of research.
Chapter 2 - Satellite to sensor field system presents several industrial satellite systems and low
cost satellite systems with CubeSat. An abstract interaction for satellite communication with a
specified scenario and the building of network structure are described respectively.
Chapter 3 - Mobile and fixed interaction algorithms designs three distributed algorithms for
synchronous WSN and evaluates the computing performance, power consumption in Occam envi-
ronment.
Chapter 4 - Memory management and simulation on GPGPU describes how the shared memory
is managed on GPGPU for the simulation based on three verified algorithms. It also presents the
data transaction and execution management controller for the simulation in realtime.
Chapter 5 - Conclusion and discussion concludes the contributions of research as well as the
future work plan.
Acknowledgements
Special thanks to professor Bernard Pottier as well as my closed friend Pierre-Yves and all
of colleagues in Lab-STICC, UBO. I am very appreciated for your supports in not only research
activities but also in my daily life in France. The last, but not less important is my family, thanks
for always be my side and encourage me during my time at USTH and UBO.
Nguyen Huu Van Long, Brest, France, 29/09/14
Contents
1 Introduction 1
1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem/Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Research work flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Satellite to sensor field system 4
2.1 Satellite systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Wireless sensor network [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Application scenario for satellite communication [1] . . . . . . . . . . . . . . . . . . 7
2.4 Abstract interaction between Satellite and WSN . . . . . . . . . . . . . . . . . . . 8
2.5 Model for system architecture and behaviors [2] . . . . . . . . . . . . . . . . . . . . 10
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Mobile and fixed interaction algorithms 14
3.1 Algorithm development motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Synchronous network system [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Anticipated algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Transaction algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Flow algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Algorithm analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Memory management and Simulation on GPGPU 31
4.1 Cuda implementation with NetGen . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Memory management on GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Data transaction in communication protocols . . . . . . . . . . . . . . . . . . . . . 34
4.4 Execution management controller the simulation with NetGen . . . . . . . . . . . . 35
4.5 Simulation experiment on GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
i
CONTENTS
5 Discussion and conclusion 38
5.1 MiCas project contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Future works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A Appendix 40
A.1 VisualWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.2 Text Editor (gedit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.3 Command line profiler nvprof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.4 Algorithm and simulation implementation . . . . . . . . . . . . . . . . . . . . . . . 40
A.5 Research contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Bibliography 41
ii
List of Figures
2.1 A Norwegian CubeSat - NCube-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Diagram of different network topologies. Image from [4] . . . . . . . . . . . . . . . 6
2.3 Sensor network with sink and gateway . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Scenario in communication between Satellite, gateways fields and a drifting buoy . 8
2.5 QuickMap’s main window displaying the world map. (map source comes from Open-
StreetMap) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 GPredict Interface with information of specific satellite . . . . . . . . . . . . . . . . 9
2.7 The satellite path, and a sensor field. The green lines and the red lines show when
a radio link is established and deleted respectively. . . . . . . . . . . . . . . . . . . 10
2.8 Network generator tool set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.9 A random network topology generated by NetGen . . . . . . . . . . . . . . . . . . 11
3.1 Simple state machine for broadcasting Bounding Box . . . . . . . . . . . . . . . . . 16
3.2 Transaction protocol implement in satellite communication . . . . . . . . . . . . . 17
3.3 Automation management for downward propagation . . . . . . . . . . . . . . . . . 19
3.4 Automation management for upward propagation . . . . . . . . . . . . . . . . . . . 20
3.5 Data transaction in round with network 50 nodes . . . . . . . . . . . . . . . . . . . 21
3.6 Flow protocol implement in satellite communication . . . . . . . . . . . . . . . . . 22
3.7 Automation management for upward propagation . . . . . . . . . . . . . . . . . . . 23
3.8 Data transaction in round with network 50 nodes . . . . . . . . . . . . . . . . . . . 25
3.9 Test results in time execution (ms) with Node’s range=1000 meters . . . . . . . . . 26
3.10 Test results in time execution (ms) with Number of nodes=50 . . . . . . . . . . . . 27
3.11 Test results in time execution (ms) with Node’s range=1000 meters, Number of
node=50 nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.12 Test results in time execution with time travel of satellite . . . . . . . . . . . . . . 28
4.1 Memory exchange in computing the global values . . . . . . . . . . . . . . . . . . . 32
4.2 A simple net with 3 connected nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Initial state of communication manager without satellite communication . . . . . . 33
4.4 Dynamic state of communication manager with satellite communication appears . 34
4.5 Data transaction between GPGPU and CPU for protocol algorithms . . . . . . . . 34
4.6 Simulation interface at high level control . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7 Debugger interface at high level control . . . . . . . . . . . . . . . . . . . . . . . . 36
iii
List of Tables
3.1 Power consumption (U) for a node in anticipated algorithm . . . . . . . . . . . . . 29
3.2 Power consumption (U) for a node in transaction algorithm . . . . . . . . . . . . . 29
3.3 Power consumption (U) for a node in flow algorithm . . . . . . . . . . . . . . . . . 29
3.4 Power consumption (U) for network 50 nodes with three algorithms . . . . . . . . 30
4.1 Results on GTX480 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Results on GFX680 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
iv
1
Introduction
This chapter presents an overview about the context as a part of MiCas (Micro satellite
et Reseau de capteur sans fils) project in section 1.1. In section 1.2 the problems and
motivations are presented. Next, in section 1.3, due to the presented motivations, a
research work flow is introduced step by step. Finally, in section 1.4, the research
objectives are presented.
1.1 Context
The internship work is a part of MiCas project (Micro Satellite et Reseau de Capteur sans fils)
in LabSTICC, UBO. Micas project objective is develop and experiment solutions to coordinate
systems which will exchange data as well as control information between several distributed wireless
sensor networks (WSN) and several ground stations by using low cost micro satellites. The project
focus on a specification, verification and simulation of related situations : several distant WSN
have their gateways visited periodically by a mobile (satellite) on a static path.
1.2 Problem/Motivation
Wireless sensor network and sensors Wireless sensor network (WSN) is a network which
implements many autonomous sensors to monitor physical or environmental conditions and passes
the collection data to a main location [5]. Inside the WSN, there are many devices, named sensor
can detect events or changes from environment and provides corresponding output. There are
several kinds of environment data that a sensor can detect: temperature, humidity, light...[6]. In
recent years, WSN is very important in environment monitoring, such as: air pollution, forest fire
detection, landslide detection...
Distant WSN problem Most of the WSN projects is deployed in city (as example [7]), where
communication systems are abundant. Otherwise, there are several WSN projects focus to the
distant areas, such as shores, deserts, mountains, polar regions to monitor the environment changes.
With this case, it is admitted that the radio connection from the sensor nodes to gateway can be
1
CHAPTER 1. INTRODUCTION
lost or corrupted by effect of the environment. According to these problems, it is critical to propose
a (several) solution(s) to collect data periodically to ensure the well operation of WSN.
Opportunities in Satellite cooperation Obviously, with the advances in Satellites or Un-
manned aerial vehicle (UAV) technologies, the solution to collect data periodically of WSN can
be achieved by implement Satellite or UAV. Generally, most of the satellite systems are industrial
systems and closed for the research purposes like MiCas project. Fortunately, the low earth orbit
satellites (LEO satellites) [8] like CubeSat are deployed in recent years can replace the industrial
satellites for the research projects i.e QB50 project, Outernet project [9, 10], Micas project because
at least two reasons: energy budget and solution cost.
Cooperation problem However, besides the advantages in cooperation between WSNs and
CubeSat, there are several problems in data transaction:
• The correctly, reliable and adaptable protocols for data transaction between Satellite and
WSN.
• An time event scheduler for WSN and satellite behaviors because they follow different sleeps
and sampling periods.
• The limited buffering of the satellites to store and retrieve the data from ground stations.
Research motivation As the result, for the cooperation between CubeSat and WSN, it is
critical to build an application level simulation to develop and experiment the potentials as well
as the risks before real deploying in environment.
1.3 Objectives
The objective of research is to approach the geo-modelisation, communication protocol devel-
opment and simulation for the interaction between CubeSat and WSN. This work also relates
to system investigations, based on the simulation of thousand of nodes in distant area, where
CubeSat visits them, collects data, connects to ground stations and controls sensing operations.
Consequently, during the internship, there are several objectives need to be achieved:
Geo-modelisation on QuickMap To model the geo location of WSN, CubeSat trajectory and
the interactions between them. Moreover, in QuickMap, it allows to generate random network
topology in specified area, to record satellite path based on tracked longitude, latitude from GPre-
dict software (see chapter 2).
Protocol developing in Occam environment To develop the communication protocols, we
propose to use Occam structure because it uses micro threads and blocking channels ([11]) which
are suitable for mono and multi-processors simulation of WSN (as shown in [12]) (see chapter 3).
Protocol implementing on GPGPU Meanwhile, the verified protocols will be implemented
on GPGPU to simulate the sensing activity, the network activities, and interactions with satellites
because GPGPU is attractive in synchronous message passing in WSN due to their Single Instruc-
tion Multiple Data - SIMD like architecture, shared memory (see chapter 4). In addition, it also
2
CHAPTER 1. INTRODUCTION
useful to simulate the physical process due to the massive parallelism present in situations such as
flooding, fires, pollution [13].
1.4 Research work flow
According to the research objectives, the report will describe the work flow as below:
Step 1 Using a map browser, QuickMap [14], to manage geo location of WSN and satellite tra-
jectories and to model the interaction between them. A satellite tracking software, GPredict
(see [15]), is used as an external process to passed the satellite paths and information to
QuickMap (chapter 2)
Step 2 Using NetGen tool set [2] to generate the network topology from specification data of
WSN fields and Satellite on QuickMap. The network topology can be generated into Occam
structure or Compute Unified Device Architecture (CUDA) structure (chapter 2).
Step 3 Developing and analyzing the distributed protocol algorithms for the cooperation between
Satellite and WSN based on generated Occam structure (chapter 3).
Step 4 Using these proposed algorithms to develop a simulation with CUDA architecture on
General Purpose Graphic Processing Units (GPGPU) (chapter 4). Moreover, proposing a
specific debugger interface which allows to manage the simulation execution at high level.
3
2
Satellite to sensor field system
The industrial satellite system has an important role in space exploration. However, be-
sides the advantages, they have the drawback in finance for deployment and investment.
Fortunately, there are several projects appear to propose a solution by using the pico
satellite (CubeSat) in research, see section 2.1. Meanwhile, the Wireless sensor net-
work has several specified characteristics to support the communication with Satellite, see section
2.2. Hence, there are several application scenario for satellite communication are presented and
a simulation strategy is described based on one of these scenario, described in section 2.3. An
abstract interaction with geographic specifications for WSN and satellite is described in section
2.4. Finally, a model for system architecture and behaviors is proposed for the simulation from
geo-location data, described in section 2.5.
2.1 Satellite systems
2.1.1 Industrial satellite systems
Argos systems The mission of Argo system is collecting and managing data about environment
and climate data around the world [16]. It is a huge system with 60 ground stations and 21.000
platforms around the world. As a result, information is relayed via the Argos satellite system and
is used for numerous applications ranging from: ocean observations, monitoring water resources,
managing marine resources.
Iridium systems Meanwhile, the Iridium network is a global satellite communication service
that provides service for subscribers from government agencies and public citizen [17, 18]. Powered
by a global constellation of 66 cross-linked satellites, the Iridium network provides high-quality
voice and data connections over the planet through the entire surface, including across: oceans,
airways, and polar regions [19]. As consequence, Iridium operates as the most reliable satellite
constellation currently available.
Advantage and critical drawback These both systems were established as a global satellite
constellation of the low Earth orbiting (LEO) satellites [20]. By using these LEO satellites, these
4
CHAPTER 2. SATELLITE TO SENSOR FIELD SYSTEM
systems supply the abilities in earth observation to track the surface of the Earth while using less
power for a successful transmission. Even though these advantages are precious and potential, the
services are still expensive and closed for the scientific community. Therefore, a new system with
low cost satellites need to be proposed to satisfy the strong desire in space exploration of scientific
community, i.e Micas project.
2.1.2 CubeSat projects
QB50 Project The QB50 project plans the possibility of launching a network at least of 50
very low-cost satellites [9]. QB50 project’s objective is to approach the researches within the lower
thermo-sphere, which is the least explored layer of the atmosphere.
Outernet Project The Outernet is a global networking project currently under development by
the Media Development Investment Fund (MDIF) [10]. Outernet project aims to provide informa-
tion broadcast service especially in the remote regions without Internet links through geostationary
and Low Earth Orbit satellites.
CubeSat opportunities As result, CubeSat is the only realistic option to full fill the proposed
missions of these projects [21], see figure 2.1. The technical details of CubeSat can be found here,
see [22].
Figure 2.1: A Norwegian CubeSat - NCube-2
CubeSat are smaller, cheaper and faster to develop than the big satellites but they have same
capabilities in communication. Therefore, CubeSats is a good educational objective for the uni-
versities in developing, launching and operating space projects, like MiCas project.
2.2 Wireless sensor network [1]
Wireless sensor network (WSN) [4, 5] A network which implements many autonomous
sensors to monitor physical or environmental conditions and passes the collection data to a main
location. The WSN are bi-directional, also enabling control of sensor activities. The WSN is
formed by the ”nodes” from a few to thousands of nodes. The connections (physical or logical)
between these nodes in network perform the network topology, see figure 2.2.
5
CHAPTER 2. SATELLITE TO SENSOR FIELD SYSTEM
Figure 2.2: Diagram of different network topologies. Image from [4]
Sensor nodes [6] Each node represents for a sensor which connects to the other sensors inside
the network. A sensor node can sense several type of environment data, such as: temperature,
humidity, oxygen quality... It also contains several hardware parts: a radio transceiver with an
internal antenna or an external antenna to receive and send data, a micro controller, an electronic
circuit and an energy source, i.e battery.
Wireless sensor network technology [1] The overall protocol architecture composes:
• ZigBee standardization (low cost, low power consumption, two ways communication) for
network layer and application layer (more in [23]).
• IEEE 802.15.4 standardization for lower layers, i.e Physical layer or MAC sublayer (more in
[23]).
Within the WSN, ZigBee/802.15.4 standard allows three frequencies: 868MHz, 915 MHz and
2.4 GHz that will allow short or medium range (10-100 meters) communications between nodes.
Synchronous sensor network [1] Obviously, WSN works like a hierarchical two-stage syn-
chronous network.
The first stage is for sampling physical processes, as it is the normal definition of WSN. This
stage produces synthetic information into sinks or gateways by using ZigBee/802.15.4 standard.
A sink is the most energy efficient node and can be the same with the gateway. Several sinks can
connect a sensor field to the visiting satellite, and their activity can be coordinated.
The second stage, the gateway listens to transactions signal from the satellite, to select and send
data to a satellite. Gateways have energy support and hardware for receiving and transmitting to
the satellite. The gateways, should be placed in a strategic position to communicate with satellites
with few terrestrial support, see figure 2.3.
6
CHAPTER 2. SATELLITE TO SENSOR FIELD SYSTEM
Figure 2.3: Sensor network with sink and gateway
2.3 Application scenario for satellite communication [1]
There are several application scenario are proposed to use Satellite communication based on
the objective of WSN
• Monitoring and surveillance: a combination between surveillance/monitoring of remote areas
and environmental monitoring. In this case, there are several specific scenarios: monitoring
water resources, managing and protecting ocean resources, tracking adventurers and yacht
races.
• Emergency communications: a large number of sensors could be randomly deployed in inac-
cessible areas for disaster relief operations, i.e forest, mountain, dessert.
• Critical infrastructures: critical buildings and facilities, such as power plants, airports and
military bases, have to be protected against potential intrusion.
In our research, Monitoring and Surveillance is proposed to be the application scenario which
can be illustrated by the our simulation. As example, in figure 2.4, there is the communication
between Satellite, drifting buoy and WSN.
7
CHAPTER 2. SATELLITE TO SENSOR FIELD SYSTEM
Figure 2.4: Scenario in communication between Satellite, gateways fields and a drifting buoy
Scenario description The satellite or drifting buoy, they can be called by an abstract definition:
a mobile. The idea is the mobile periodically visits the remote area WSNs to collect the sensed
data, refreshing control information [1] . As a result, the mobile can monitor multiple WSN in
several areas. Otherwise, the distributed sensor network can exchange the data by using the mobile.
With the collected data , the scientists can analyze and predict the ocean resources as well as the
change of coastal areas, where near real-time observations at the sea surface.
Simulation strategy The data for position in real time of mobile, gateway fields are represented
on QuickMap [14]. Then, an abstract network is produced by NetGen with its equivalent topology
on Occam and Cuda structure, excluded mobile. The mobile is integrated or removed to the
topology of network based on its relation with network. The algorithm protocols are proposed,
verified and implemented on Occam environment. The results of algorithm protocols are displayed
on simulation in GPGPU according to the movement of mobile in real time. As consequence, the
following sections will describe how the abstract interaction between WSN and Satellite is modeled
on QuickMap (in section 2.4) and the network topology generation by NetGen (in section 2.5).
2.4 Abstract interaction between Satellite and WSN
Geographic specifications Map browsers are now of common use, and it is an evidence that
sensor distributions necessitate such tool to ease sensor field description and exploration/evalu-
ation. When interactions with mobile flights are considered, additional supports include mobile
path description, radio link computations, system state graphic representation and further human
interaction.
Obviously, Google Map or Open Street Map browser have many supports for the user in de-
veloping their application. However, they can not be integrated well with a set of tools in level
simulation for sensor network, like NetGen tool. In addition, they don’t support an adequate frame-
8
CHAPTER 2. SATELLITE TO SENSOR FIELD SYSTEM
work to design and implement the distributed algorithms. Therefore, a new browser was designed
at UBO, QuickMap [14], which integrates well with NetGen [2]. QuickMap displays geo-referenced
objects, as sensors and satellites, on a base map (figure 2.5).
Figure 2.5: QuickMap’s main window displaying the world map. (map source comes from Open-StreetMap)
WSN and satellite interaction Geographical information, and time sequenced are the key
points to consider these relations. Several software packages allow to retrieve and interpret satellite
path information from public repositories. As a reference example, GPredict [15] is a public domain
software with lot of operational capabilities based on the prediction of satellite paths: real time
track characteristics, schedule table, footprint, communication establishment, control of antenna.
Computation of positions and speed is based on keplerians elements of its orbit, these parameters
being provided by public servers, see figure 2.6.
Figure 2.6: GPredict Interface with information of specific satellite
Practically, satellites have predictable track, that can be described by algorithms or by discrete
sequences of events ((time,position) ...). To bind mobiles to sensor fields, it is necessary to share
9
CHAPTER 2. SATELLITE TO SENSOR FIELD SYSTEM
time references and geographic positions. For this reason, QuickMap was interfaced to GPredict,
grouping mobile and sensor networks models.
Sensors positions and satellite tracks are sent to NetGen (section 2.5), to compute the topology
of the network, and predictable satellite connection. The map browser can now extract or record
satellite paths, display them graphically with expected ground communication links with the sensor
field [24] (figure 2.7).
Figure 2.7: The satellite path, and a sensor field. The green lines and the red lines show when aradio link is established and deleted respectively.
2.5 Model for system architecture and behaviors [2]
NetGen has been developed using Smalltalk, a powerful object-oriented language [25]. Smalltalk
is available on different platforms such as: VisualWorks, from Cincom, VisualAge, from IBM,
Pharo, coming from free software community.
It is a set of tools enabling application level simulation for Wireless Sensor Networks [2], see
figure 2.9. A network is therefore a large data structure grouping nodes and their associated links.
Figure 2.8: Network generator tool set
NetGen allows to generate abstract network which represents for WSN in order to make the
simulation. The generated abstract network has two parts: the network topology and the behavior.
The execution of abstract network generated by NetGen follows the synchronous communication
model (more in chapter 3) where the process presents for the sensor. The sensor node (process) is
engaged in a program which simulates the Waiting, the Communication and the Status change of
10
CHAPTER 2. SATELLITE TO SENSOR FIELD SYSTEM
node. The abstract network generated by NetGen can be expressed like text below:
P1 { P2 } Node
P2 { P1, P3 } Node
P3 { P2, P4, P5 } Node
...
or a logical graph:
Figure 2.9: A random network topology generated by NetGen
Meanwhile, the network behavior is defined by a function (in Occam or Cuda code) which will
be executed by all nodes in parallel under the management of synchronisation.
Obviously, in our research, NetGen is used to produce concurrent programs that separate
almost completely the algorithmic and organization contributions, enabling to use and control
huge number of nodes from distributed algorithms [3], whatever is the architecture topology.
Thus, the design framework should be proposed to support for two abstractions:
• the system architecture description are the set of nodes and their communication links
• the behaviors are local programs coopering by message exchanges
2.5.1 Building abstract network
Network topology are expressed internally on a simple network model, as named nodes and
communication links [2]. In NetGen framework, the most commonly topology are automatically
generated expressed in Occam structure and CUDA structure.
Occam structure In Occam, node (process) exchanges data with the others by using bi-directional
channels, named Channel In for receive and Channel Out for send. Thus, the communication be-
tween sensor nodes or the network topology can be expressed like:
-- Configuration for processes
VAL [15 ] [3] BYTE NetProcess IS [ "P1" , -- id assigned: 1
"P2", -- id assigned: 2
"P3", -- id assigned: 3
...
-- Node communication by channel or network topology
P1.out IS [P1.P2]:
P1.i n IS [P2.P1]:
P2.out IS [P2.P1, P2.P3]:
P2.i n IS [P1.P2, P3.P2]:
...
To compile the Occam code, there is an Occam compiler is developed at Kent University can
be used [26].
Occam uses micro threads and blocking channels ([11]). It is suitable for mono and multi-
processors simulation of WSN (as shown in [12]), for distributed execution, and for local micro
controller unit, either in the form of virtual machines or native code.
11
CHAPTER 2. SATELLITE TO SENSOR FIELD SYSTEM
Cuda structure CUDA is a programming software associated with Graphic Processing Units
which is designed by NVIDIA. With Cuda technology, it allows to use GPGPU to execute the
calculation in parallel. In Cuda, node (process) exchanges data with the others by using a share
memory. Hence, it is necessary to declare the nodeState structure for each node and a message
with id. Thus, the structure of node state and declaration of exchanged message can be expressed
like:
/* structure for node state*/
struct nodeState {
int initial , current ;
int globalComputing ;} ;
typedef struct nodeState nodeState ;
/* id of node and message declaration for transferring in network */
typedef int id ;
typedef int message ;
2.5.2 Network behavior implement
A nice effect of this software approach is that the node behaviors can be specified, validated,
and stored in the form of Occam or CUDA libraries.
Node behaviors group several activities for sensing, for making local decisions that will appear
as a change in the node state, and for exchanging with neighbours [2]. It also follows the more
common way to describe distributed algorithms, and particularly synchronous, self timed behaviors
[3]. In the synchronous model, each node executes cycles for change of state (Ci), message out (Mi),
and message in (Ni). Thus, our simulation program will execute similarly sensing and sleeping,
communication phases, and making of decisions.
Such behaviors are strongly bound to the synchronous model, the handling of communications
on links being executed by procedure calls. The programming pattern is a loop grouping commu-
nications, buffer analysis and sense data analysis to obtain local change of state, then starting of
sensing/sleeping activities.
Occam behavior The sensor activity is presented by the process and each process executes the
same program, the behavior. Thus, the implement behavior can be proposed like below:
PROC NodeBehavior (CHAN OF INT Incoming.Chan , Outgoing.Chan , VAL INT Identity)
INT Incoming.Value :
SEQ
-- initialisation code here
WHILE TRUE
SEQ
DO SOME WORK HERE -- Step 1: sensing
PAR -- Step 2: communication
Outgoing.Chan ! Local.Value
Incoming.Chan ? Incoming.Value
SKIP -- Steo 3: sleeping
:
Cuda behavior While Occam represent communications by point to point blocking message
sending, CUDA is operated by synchronized exchanges in GPGPU memory. GPGPU are using the
notion of Kernels executing in parallel a sequential procedure. A kernel is a function for network
behavior which is implement in sequential but is executed in parallel by the process (computing
element), consider that networks are acting synchronously[27]. Inside the kernel it is mandatory
to specify the thread Id and number of thread to be used to compute [28].
12
CHAPTER 2. SATELLITE TO SENSOR FIELD SYSTEM
The data exchange are executed by automaton based on a description of copy operations to
and from neighbour buffers. The list of these operations is produced automatically by NetGen
CUDA translator to represent and use the connectivity. The size of the communication program
is adapted to the maximum fan-out inside the network (see [29] for technical details).
2.6 Conclusion
This chapter presents briefly about several industrial satellite systems and their drawback in
finance of deploying. Thus, the other space exploration projects with CubeSat can be proposed
as a better solution. Based on the WSN characteristics, there are several scenarios to apply the
satellite communication. With one specified scenario, the simulation strategy is described. Follow
the strategy, an abstract interaction between Satellite and WSN is shown by using QuickMap and
GPredict. Finally, topology and behaviors of sensor field are generated by NetGen in approach the
simulation on Occam and Cuda respectively.
13
3
Mobile and fixed interaction
algorithms
This chapter presents the motivation for protocol algorithm development in section 3.1.
WSN operates as a synchronous network system, therefore it is important to know how
it operates in section 3.2. Next, according to the synchronous WSN, three algorithms
for satellite corporations are proposed on Occam environment respectively in section
3.3, 3.4, and 3.5. Finally, the computing performance as well as the power consumption of each
proposed algorithm is analyzed in section 3.6.
3.1 Algorithm development motivation
Following the Monitoring and Surveillance application, the data transaction between Satellite
and WSN can happen with scenario like below:
• The proximity of the arrival of a satellite is known. This case is named Anticipated (section
3.3).
• Satellite sends a command at its first contact with the sensor field, which propagates the
command and executes distributed computation dynamically. The command must flow inside
the sensor field with results sent back to the satellite. This case is named Transaction (section
3.4).
• Satellite sends a command which is processed on the fly in the sensor network, with the
results forwarded to an exit node where the satellite can receive it. This case is named Flow
(section 3.5).
Objectives Obviously, all of these data transaction cases are operated and implemented in a
synchronous WSN system. Thus, it is critical to understand well how a synchronous network
system operates and to develop the adaptable algorithms for these above data transaction cases
(see section 3.2).
14
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
3.2 Synchronous network system [3]
Consider that the components (sensor nodes) take steps simultaneously, that’s mean they ex-
ecute in synchronous rounds. Understanding how to solve a problem in the synchronous model is
very useful in understanding how to solve it in other realistic models.
A synchronous network system consists of a collection of computing elements (processes) located
at the nodes of a directed network graph. Generally, a process consists the following components:
states, start, msg, and trans, more details in [3]. From beginning of execution, all processes in
arbitrary start states and all channels are empty. Then, the processes will perform repeatedly these
two following steps (combine to round):
• Generate the messages to sent to all outgoing neighbors. Put these messages in the appro-
priate channel (Channel Out).
• Change to new state based on the current state incoming messages (Channel In). Remove
all messages from the channels.
For data transaction between nodes in network, we can define diameter as the longest path
among several shortest paths in network. Obviously, diameter steps are needed that include com-
munications between neighbors and local computation. The following sections show how algorithms
are expressed as Occam automata to obtain simulation and performance evaluation.
3.3 Anticipated algorithm
3.3.1 Problem statement
When a mobile arrives over a sensor field, the mobile is a special node in our network, the
dynamic node. The global computation is achieved by broadcasting the result between the nodes.
Each time the mobile moves, the global computation is updated real-time. Hence, each node will
know the global result of computation in network. According to this scenario, an application is
proposed in which the data need should be prepared to be sent or interacted with previous satellite
visit. The bounding box computation is a good way to show how this algorithm works.
Based on the synchronous network system, it is possible to develop and analysis the distributed
algorithms in global computing, for example: Leader election, breadth first search BFS, minimum
spanning tree MIS...
3.3.2 Algorithm informal description
Suppose that each node has a ”special status”, it could be its local range, called Bounding Box.
The nodes in network have two channels to communicate and exchange the messages. By this
way, a node broadcast the message to notify its neighbors about its ”special status”. Obviously,
the node also receives the other nodes’ messages will make an update based on its current status
and the income status. In next communication cycle of network, it will start a new broadcasting
with new result or not to the neighbors. The maximum time for this global computation is equal
to diameter of network. As a result, the node should stop to update within this limitation and all
nodes will have the global result.
15
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
3.3.3 Message broadcasting protocol
The execution of all proposed algorithms is controlled by the diameter constraint. The algorithm
execution will be done in synchronous mode, described in Figure 3.1
Figure 3.1: Simple state machine for broadcasting Bounding Box
In this algorithm, the broadcast message contains the local status of node, i.e the BoundingBox.
At the first time, each node is initialized with the local result or local BoundingBox. Each node’s
Bounding Box is initialized based on the location getNodeLocation(i), range getNodeRange(i)
and two points (upper left and bottom right). These two points are located by: (location− i) and
(location + i) respectively.
Initialization
At t=0
AllNodes.initialize
When a node receives messages from neighbors, it updates its status (merges the Bounding
Box) and prepares to broadcast the new status in next round of communication. To merge the
Bounding Box into a new one, it should compare the minimum of Upper Left and maximum of
Bottom Right between the Bounding Box.
UpdateTransaction
while (i < Node.neighbors)
Set(outMessages[i]) -- receive the message from neighbors
Set(inMessages[i]) -- send the message to neighbors
Node.updateResult(Node.status , inMessage[i]. status)
After diameter steps computing, all nodes in network have already updated the last Bounding
Box.
GlobalComputing
Initialization
while (i < diameter)
Node[i]. UpdateTransaction
This algorithm bases on the scenario in which the proximity of satellite’s visit is known. As a
result, the command signal is not emitted by satellite because satellite travels and operates as a
node in network field. Hence, it is not a good solution for dynamically transaction between satellite
and sensor network.
3.4 Transaction algorithm
3.4.1 The problem
Mobile arrives over a sensor field and obtains a connection with one gateway see figure 3.2.
It sends a command to the gateway which will be chosen as Root of network tree to request the
execution of a global computation implying a visit of every node in the field. After a moment, it
16
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
is expected that a result message will be sent back by the gateway to the mobile. The Root node
will have the Global result of computation.
Figure 3.2: Transaction protocol implement in satellite communication
In the figure 3.2, if the satellite can receive the result at position 1 while it still in range
of gateway, the communication is successful. Otherwise, it will miss the result when moving to
position 2.
Each node contributes to the computation in a commutative way. As examples: computation
of the field bounding box, global status, maxima.
3.4.2 Tree expanding algorithm
BFS algorithm In this approach, BFS performing is a critical motivation because the BFS tree
minimizes the maximum communication time from the process at the distinguished node to all
other processes in the network [3]. As an advantage, BFS algorithms can be used or augmented to
hep in performing the tasks, i.e: broadcasting, global computation, electing the leader, computing
the diameter.
SBFS algorithm Consider that network as Tree structure with several kinds of node: Parent
node, Children node, Leaf node and Root obviously. The synchronous BFS or SBFS produce a
BFS tree by sending a searchmessage to all outgoing neighbors.
3.4.3 Algorithm informal description
Based on the Synchronous BFS, the dynamically downward and upward links allow to imple-
ment the global computations.
Downward link In downward approach, suppose that a root node sends a search message car-
rying the command. Each other node will receive the command at one step of the synchronous
loop. At the first time and only at this time, one parent is elected and informed. Each other
neighbor will receive ”search” at next step. After diameter step, all the node in network is prop-
agated successfully the search message, from the Root to the last node, the Leaf. In addition,
the relationship between nodes: parent index and list of children is established for next backward
algorithm to propagate the result.
17
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
Upward link The upward operation starts in nodes after search propagation, without parent
notification. At this time, a local result is produced and sent to the parent node. As soon as the
parent node receive the partial results from children, it computes its local contribution and waits
for next result It will send the its final contribution upward as it collected and computed all the
results from children. By this way, after diameter step in computing, the Root will receive and
update the result to make a global result before sending it to mobile.
Obviously, combining two algorithms, upward and downward, the total time Root node will
receive the global computation result is at most diameter×2+1 steps. As consequence, connection
between mobile and gateway must be active over this delay.
3.4.4 Message protocol and transaction buffers
Messages in the algorithm are null, request, parent, result. In the Occam implementation, a
protocol is presented that associates data to these messages, with a customization for bounding
box computation:
PROTOCOL trans.proto
CASE
BBoxRequest; BYTE -- tag for request command with dummy data
BBoxParent ; BYTE -- tag for parent answer with dummy data
BBoxResult ; BoundingBoxArea -- tag for result with a rectangle
SendNull ; BYTE -- dummy data
There are several definitions for the message type for our upward and downward algorithms:
• BBRequest: a search message, it is propagated from a node to all of its outgoing neighbors.
• BBParent: an answer message from the outgoing neighbors to the original node.
• BBResult: Bounding Box result is sent backward from the Leaf to the Root
• NullMessage: a null message contains nothing, reset the message buffer in next round com-
munication.
In Occam simulation, each process (node) has two channels: ChannelIn and ChannelOut for
data communication. Hence, to store the income messages and send massage of these channels,
the buffer structure is designed: BuffIn and BuffOut respectively. Obviously, the messages are
stored in these buffers by the unique index for each type of message.
INT BufIn [MaxInNeigbors]
INT BufOut[MaxInNeigbors]
3.4.5 State definition
Nodes retain their local state in a set of variables. It is needed to point to a possible parent
and possible children. Previous visits can be represented as Boolean. The sensing status is figured
by the geographic position in a bounding box rectangle, to be updated. In Occam, the state is
expressed by a set of variables:
DATA TYPE OrderedCollection
RECORD
INT NbChildren: -- reflect number of children , initially 0
[MaxFanOut] INT tabOfChildren: -- index of channels toward children
:
INT indexParent: -- index toward parent , initially -1
18
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
OrderedCollection TabOfChildren: -- initially empty
INT remainingChildren: -- number of children we are waiting for
BoundingBoxArea currentBoundingBox: -- bounding box to be updated state
In downward approach, the local automaton state is kept in a variable state, with possi-
ble values: StateInit, StateSendRequest, StateReceiveParent, StateEnd, and from the beginning
initiallystate = StateInit.
Meanwhile, in upward approach, the possible values are: StateReceiveResult,StateSendResult, StateIdle,
and from the beginning initiallystate = StateReceiveResult.
Downward request propagation
In figure 3.3 describes the automation management of downward.
Figure 3.3: Automation management for downward propagation
According to the state, the local automaton will fill message buffers to the neighbours according
to the following patterns. In the initial state, nodes are waiting for BBRequest. Upon reception,
output buffer are filled with BBParent, or BBRequest messages.
StateInit :
IF Request.received.somewhere
Keep(indexParent)
Set(BufOut[all],BBRequest)
Set(BufOut[indexParent],BBoxParent)
nextState := StateSendRequest
ELSE
Set(BufOut[all],SendNull)
After sending BBRequest, any node is interested to learn about children and thus switch to
StateReceiveParent.
StateSendRequest :
Set(BufOut[all],SendNull)
nextState := StateReceiveParent
In this state, children are registered in TabOfChildren structure of Parent node.
StateReceiveParent :
IF BufIn[i] = Parent
AddChildren (TabOfChildren , i) -- add children to parent ’s collection
TabOfChildren.NbChildren := TabOfChildren.NbChildren + 1 -- increase children counter
ELSE
Set(BufOut[all],SendNull)
nextState := StateReceiveParent
Node go to this idle state after propagating the request (if possible) and asking for the parent
StateEnd :
Set(BufOut[all],SendNull)
nextState := StateEnd
19
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
Upward result sending back
In figure 3.4 describes the automation management of upward.
Figure 3.4: Automation management for upward propagation
According to the state, the local automaton will fill message buffers to the neighbours according
to the following patterns. In the initial state, node are waiting for BBResult. Upon reception,
node updates the local contributions and send upward its final contribution if there are no more
results from its children. Otherwise, the output buffer are filled with SendNull messages to continue
to wait.
StateReceiveResult :
IF Result.received.somewhere
MergeResult (CurrentResult , BufIn[indexReceived ]) -- update from local contributions
remainingChildren := remainingChildren - 1 -- decrease children counter
IF remainingChildren == 0 THEN
Set (BufOut[indexParent], BBResult) -- send upward node ’s final result
nextState := StateSendResult
ELSE
Set(BufOut[all],SendNull) -- otherwise , continue to wait
After sending upward the result, node go to StateSendResult and next StateIdle. In fact, in
case with Root, it will go to Idle state after sending the global result of computation to mobile.
StateSendResult :
Set(BufOut[all],SendNull)
nextState := StateIdle
StateIdle :
Set(BufOut[all],SendNull)
nextState := StateIdle
Example with network 50 nodes To illustrate how the algorithm works in communication
rounds, an example network with 50 nodes is presented in Figure 3.5 The Root node of tree has
id=9. The red link is the downward part and the blue link is the upward part. The satellite sends
the command signal at R1 and receive back the global result at R1 also.
20
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
P43
P48
r= 1
P10
r= 9
P13
r= 1
P15
r= 1
P20
r= 1
P31
r= 1
P35
r= 1
P36
r= 1
P39
r= 1
r= 6
P2r= 2
P3r= 2
P40r= 2
r= 0
P1
r= 0
P5r= 0
P6
r= 0
P33
r= 0
P38
r= 0
Root
r= -1
P26
r= 0
P29
r= 0
P30
r= 0
r= 7
P4r= 1
P8r= 1
P45r= 1
P34
r= 1
r= 5
r= 5
r= 5
r= 5
r= 5
r= 6
P7
r= 1
P11
r= 1
P17
r= 1
P18
r= 1
P21
r= 1
P24
r= 1
P28
r= 1
P42
r= 1
P44
r= 1
P47
r= 1
r= 5
r= 5
r= 6
P9r= 1
P12r= 1
P16
r= 1
P23
r= 1
P27
r= 1
P41
r= 1
r= 5
r= -1
r= 5
r= 5r= 5
P46 P14r= 3r= 7r= 6
P19r= 4
r= 5
r= 5
r= 5
r= 5
r= 5
r= 5
r= 5
r= 6
P22r= 2
P25r= 2
P49
r= 2
r= 5
r= 5
r= 5
r= 5
r= 6
P32r= 1
P37
r= 1
r= 5
r= 5
r= 5
r= 5
r= 5
r= 5
r= 6
P50
r= 2
r= 5
r= 5
r= 5r= 8
r= 2
r= 5
r= 5
r= 5
r= 5
r= 5
r= 5
r= 5
Figure 3.5: Data transaction in round with network 50 nodes
21
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
Obviously, this algorithm proposed a better solution than the first algorithm. Using a gateway
operates as Root of network tree to receive signal and send back result to the satellite. However, the
drawback is explored when movement speed of satellite is faster than computing speed of network:
The time constraint.
3.5 Flow algorithm
3.5.1 The problem
In previous second algorithm, the most critical problem is time constraint in computing the
global result and sending back to satellite. Hence, the propagated result from Root to satellite
can be missed easily. As a better solution, the well trusted distributed network is proposed which
can receive, compute and send back the result to satellite before leaving. The advantage of this
algorithm is the strategy in using 2 BFS tree to receive command in one gateway and propagate
result in another gateway. As result, if the computation time is terminated before satellite leaves
the network, the satellite can receive well the global result, see figure 3.6.
Figure 3.6: Flow protocol implement in satellite communication
As in figure 3.6, using the first gateway to receive request and the second gateway to send back
result allows a successful communication even if satellite is in Position 2.
3.5.2 Algorithm informal description
In this algorithm, there are two BFS trees are defined inside the network. According to the BFS
trees, the first Root is elected as the first gateway to receive the command signal of satellite when
it passes over the node field. In contrast, the second Root is elected as the second gateway to send
back the result of computation just before satellite leaves the node field. In the third algorithm,
consider that two BFS trees are already explored before satellite enters the field. The Root of first
tree and Root of second tree will have the Global result of computation. Therefore, the structure
of protocol, messages can be reused in this algorithm. However, using the BBParent message type
anymore is not necessary. The maximum time needs for this solution in computing is diameter×4.
22
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
3.5.3 Protocol and messages
According to the Figure 3.7 has the message automaton management.
Figure 3.7: Automation management for upward propagation
Messages in the algorithm are null, request, result. In the Occam implementation, using a pro-
tocol that associates data to these messages, with a customization for bounding box computation:
PROTOCOL trans.proto
CASE
BBoxRequest; BYTE -- tag for request command with dummy data
BBoxResult ; BoundingBoxArea -- tag for result with a rectangle
SendNull ; BYTE -- dummy data
3.5.4 State definition
The structure in state expression in Occam can be presented as the second algorithm. However,
there is several new ideas need to take attention. Instead of forwarding result to Root of first tree,
the result should be forwarded to Root of second tree. Therefore, a new collection for list of children
and the index for parent node are proposed in second tree.
DATA TYPE OrderedCollection
RECORD
INT NbChildren: -- reflect number of children , initially 0
[MaxFanOut] INT tabOfChildren: -- index of channels toward children
:
INT indexParentTree2: -- index toward parent of BFS2
OrderedCollection TabOfChildrenTree1: -- initially empty
OrderedCollection TabOfChildrenTree2: -- initially empty
INT remainingChildrenTree2: -- number of children we are waiting for
BoundingBoxArea currentBoundingBox: -- bounding box to be updated
In addition, the local automaton state is kept in a variable state, with possible values:
StateWaitForSignal, StateRequestComputing, StateReceiveResult, StateSendResult,StateIdle,
and from the beginning initiallystate = StateInit.
3.5.5 Automaton management for downward and upward
According to the state, the local automaton will fill message buffers to the neighbours according
to the following patterns.
23
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
In the initial state, nodes are waiting for BBRequest. Upon reception, output buffer are filled
with BBRequest messages. In special case, the state change can be optimized when a node is a
leaf for both tree. The leaf node can send back the result in next round without waiting by change
from StateWaitForSignal to StateSendResult.
StateWaitForSignal :
IF Request.received.somewhere
IF (rootFirst[Children ][ NbFils] = 0)
If(rootSecond[Children ][ NbFils] = 0) -- a leaf node for both tree
nextState := SendBBResult -- send back the result next round
BufOut[rootSecond[indexParent ]] := SendResult
ELSE
Set (BuffOut[allChildrenOfTree1], Request)
nextState := StateRequestComputing
ELSE
Set(BufOut[all], NULL)
nextState := StateWaitForSignal
After sending BBRequest, the node from second tree are interested to learn about children and
thus switch to StateRequestComputing.
StateRequestComputing :
IF Result.received.somewhere THEN
MergeResult (CurrentResult , BufIn[indexReceived ])
remainingChildrenTree2 := remainingChildrenTree2 - 1
IF remainingChildren == 0 THEN
Set (BufOut[indexParentOfTree2], SendResult)
nextState := StateSendResult
Set(BufOut[all], NULL)
nextState := StateReceiveResult
Upon reception, nodes from second tree update the locals contributions and propagates result
upward. Otherwise, the output buffer is filled with SendNull messages to continue to wait the
children results.
StateReceiveResult :
IF Result.received.somewhere THEN
MergeResult (CurrentResult , BufIn[indexReceived ])
remainingChildrenTree2 := remainingChildrenTree2 - 1
IF remainingChildren == 0 THEN
Set (BufOut[indexParentOfTree2], SendResult)
nextState := StateSendResult
ELSE
Set(BufOut[all],NULL)
After forwarding result, the node comes to idle state, the state StateSendResult.
StateSendResult :
Set(BufOut[all],NULL)
nextState := StateIdle
StateIdle :
Set(BufOut[all],NULL)
nextState := StateIdle
Example with network 50 nodes An example network with 50 nodes is presented in Figure
3.8 The Root node of first tree has id=9 and the root node of second tree has id=5. The satellite
sends the command signal at R1 and receive back the global result at R2.
24
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
P43
P48
r= 1
P6
r= 2
P13
r= 1
P15
r= 1
P20r= 1
P31
r= 1
P35r= 1
P36r= 1
P39
r= 1
P2r= 2
P3r= 2
r= 4
P40
r= 2
P10
r= 0
P1
r= 0
P5r= 0
r= 0
r= 1
P33
r= 0
P38
r= 0
P26
r= 0
P29
r= 0
P30
r= 0
P4r= 1
P8r= 1
P45
r= 1
r= 2
P34
r= 1
r= 3
r= 3
P44
r= 2
r= 1
R2r= 9
P7
r= 1
P11r= 1
P17
r= 1
P18
r= 1
P21r= 1
P24
r= 1
r= 2
P28
r= 1
P42r= 1
r= 1
P47
r= 1
r= 2
r= 2
r= 2
P9
r= 1
P12
r= 1
P16
r= 1
P23
r= 1
P27r= 1
P41
r= 1
r= 2
R1r= -1
r= 2
r= 2
r= 2
P46 P14r= 3
r= 7
r= 6P19
r= 4
r= 2
r= 2
r= 2
r= 2
r= 5
r= 2
r= 2
P22
r= 2
P25
r= 2
r= 3
P49r= 2
P37
r= 3
r= 2
r= 2
r= 3
r= 5
P32
r= 1
r= 1
r= 2
r= 2
r= 1
r= 1
r= 2
r= 4
r= 3
P50
r= 2
r= 2
r= 2
r= 4
r= 8
r= 2
r= 3
r= 4
r= 3
r= 4
r= 2
r= 3
r= 3
Figure 3.8: Data transaction in round with network 50 nodes
25
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
Using this approach, the previous problem with time constraints is removed and the reliability
of network is enhance also in simulation.
3.6 Algorithm analysis
In this section, we analyze the performance in time execution and power consumption of three
designed algorithm.
In fact, the performance for global computing is depended by the network topology and max-
imum number of channel in/out for a node. These factors can be controlled when creating in
NetGen and QuickMap by verifying the parameters: Network’s zone, Node’s range and Number
of node in network. Therefore, three scenarios are proposed in Occam simulation to test the algo-
rithm’s performance due to these parameters. Obviously, the result of global computing is correct
for all presented algorithms, hence, we only take attention the time execution in analysis.
3.6.1 Computing performance
First scenario Consider that the Network’s zone and Node’s range (1000 meters) are constant
values. The computing performance depends on the Number of nodes in network, see figure 3.9
Figure 3.9: Test results in time execution (ms) with Node’s range=1000 meters
Generally, the predict results should be decreased in computing time because the more nodes
in specified zone, the more connection between them exists. However, the network is generated
randomly, the worst case can happen is: the connected nodes are in the same level in tree structure.
As result, these three algorithms do not change too much the result during the test.
Second scenario Consider that the Network’s zone and Number of nodes as constant values.
The Node’s range is increasing gradually from 800 meters, see figure 3.10
26
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
Figure 3.10: Test results in time execution (ms) with Number of nodes=50
The time computing decreases for all three algorithms when increasing the Node’s range in
communication. Obviously, increasing the node’s range makes more connection between the nodes.
As result, there are more nodes in same level in tree structure. Therefore, the algorithms need less
time to execute the global result.
Third scenario Consider that the Node’s range (1000 meters) and Number of node (50 nodes)
as constant values. The Network’s zone is increasing gradually from Zone 1, see figure 3.11
Figure 3.11: Test results in time execution (ms) with Node’s range=1000 meters, Number ofnode=50 nodes
The number of connection links between nodes decreases when increasing the Network’s zone.
As result, there are more levels in tree structure. Therefore, the algorithms need more time to
execute the global result.
27
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
Computing time evaluation Proposing an example in which the satellite travels through a
zone (50 nodes, node’s range is 1000 meters) with average speed 7 meter/ms. Thus, the travel
time of satellite for each node will be 142.18ms. Obviously, when the zone is increased, satellite
will travel more time over the zone. According to the Transaction algorithm, the time computing
for global result should be less than the time the satellite travels over the Root (Travel Time 1).
Meanwhile, with the Flow algorithm, the time computing for global result should be less than the
time the satellite disconnects with Second root (Travel Time 2). In technical, the time stamp is
proposed for Link creation and Link destruction for each node as Event, see more at [24]. In this
evaluation, the Anticipated algorithm is not measured because in the real case the sensor network
should receive the signal from satellite. The measurements are illustrated by the below figure 3.12)
Figure 3.12: Test results in time execution with time travel of satellite
As expected, the time computing of Transaction algorithm has a drawback with time constraint
under the satellite speed. Thus, the global result is missed to sent back from Root to satellite.
Meanwhile, the result from time computing of Flow algorithm has a good performance. Satellites
receives well the global result before leaving the Second Root.
Consequently, Flow algorithm protocol is the best solution for data transaction between satellite
and networks. For the Transaction algorithm, in case using satellite, it is limited by the time
constraint due to speed of satellite. However, in other using case, i.e Drone, UAV, it can be still
adaptable because the speed of them are not fast as satellite.
3.6.2 Power consumption measurement
Generally, each sensor node has three states in operation: idle state, send state, and receive
state. In fact, in idle state, the sensor does not consume much energy as the send state or receive
state [30]. Hence, to evaluate the power consumption of node, it should measure how many
messages will be receive and how many message will be send by node. Each message is sent
or received, node will consume 1 Unit of power, called U. Obviously, the power consumption of
network will be evaluated by the total power consumption of nodes in network.
Anticipated algorithm The message is broadcast from a node to all of its neighbors. Moreover,
one node needs diameter step to broadcast the message to the other nodes in far distance. As
result, in table 3.1 shows the power consumption of a node, with N is number of nodes’ neighbors.
28
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
Operation All
Send diameter ×N
Receive diameter ×N
Total diameter × 2N
Table 3.1: Power consumption (U) for a node in anticipated algorithm
Transaction algorithm In this algorithm, the most power consumption node is Root and the
least is the Leaf of network. As reason, the Root broadcasts the Request to all of its neighbors in
downward link and receives the Parent and Result in upward link. Meanwhile, the Leaf just send
the Parent and Result in upward link and receive the Request from a Parent node. Consequently, in
table 3.2 shows the power consumption for each type of node, with C is number of nodes’ children.
Operation Root Others Leaf
Send N N + 1 2
Receive diameter ×N N + C 1
Total N × 2 2N + C + 1 3
Table 3.2: Power consumption (U) for a node in transaction algorithm
Flow algorithm In this algorithm, the most power consumption nodes is a normal node (not
Root, not Leaf) and the least power consumption is Leaf node for both trees. In fact, the transaction
algorithm has already done the BFS procedure for tree structure. Remind there are only 2 types of
messages for global computation are: Result and Request message. Hence, the power consumption
of BFS procedure is not considered. Consequently, in table 3.3 shows the power consumption for
each type of node with C1, C2 are number of nodes’ children respectively in Tree1, Tree2.
Operation Root1 Root2 Others Leaf1 Leaf2 Leaf12
Send C1 + 1 C1 C1 + 1 1 C1 + 1 1
Receive C2 (U) C2 + 1 1 + C2 1 + C2 1 1
Total C1 + 1 + C2 C + C2 + 1 C1 + 2 + C2 2 + C2 C1 + 2 2
Table 3.3: Power consumption (U) for a node in flow algorithm
Example with network 50 nodes Using again the network from section 4.2 and 4.3. The
result is describe in the table 3.4
29
CHAPTER 3. MOBILE AND FIXED INTERACTION ALGORITHMS
Operation Algorithm 1 Algorithm 2 Algorithm 3
Send 98 687 300
Receive 98 687 300
Total 196 1374 600
Table 3.4: Power consumption (U) for network 50 nodes with three algorithms
Evaluation Obviously, the least power consumption among the algorithms is the Flow, next is
Anticipated and Transaction. However, in practical work, the power consumption also depends on
network topology. As result, the evaluation is stable when the network is big (more than hundreds)
and complex enough.
3.7 Conclusion
Synchronous network system is presented to show its important role in algorithm development.
Then, three distributed algorithms are designed for data transaction between sensor network and
satellite. Obviously, each algorithm is adaptable for specified case study. The computing perfor-
mance of algorithms are analyzed by three scenarios on Occam environment. Moreover, the power
consumption of algorithms are also explored by theoretical and practical approach. In next section,
we will show how to manage and implement these algorithms for the simulation on GPGPU.
30
4
Memory management and
Simulation on GPGPU
This chapter presents the simulation for satellite communication on GPGPU with the
verified protocol algorithms. Firstly, it introduces the NetGen supports for Cuda im-
plementation on GPGPU, in section 4.1. Then, it presents how the memory is man-
aged on GPGPU according to the designed algorithms, in section 4.2. Moreover, the
data transaction for computing of algorithms between GPGPU and CPU is explained, in section
4.3. Next, several high level execution managers are designed to control the data transaction on
GPGPU, in section 4.4. Finally, the simulation experiment on GPGPU is described, in section 4.5.
4.1 Cuda implementation with NetGen
Sequencing execution thus require the application to identify sub-systems in terms of Identity
(as example, leader node identity), Diameter (longest distance in each separated graph), Sleeping
delays between sample collection. Conservative scheduling is possible by passing these values to
the simulation kernel. These values contribute to each node state are also visible for the simulation
kernel that can organize computation following as example, the maximum of Diameters, the set
of Identities, the maximum of delays in an execution loop. Maximum, minimum and other global
values are computed as primitives at the kernel level, as reduction operations with logarithmic
costs (figure 4.1).
31
CHAPTER 4. MEMORY MANAGEMENT AND SIMULATION ON GPGPU
Figure 4.1: Memory exchange in computing the global values
As an example, the maximum Diameter can be used as a loop control inside a distributed
algorithm, and as a control parameter for the parallel simulation of several separated graphs that
have to reach their own diameter to propagate knowledge.
4.2 Memory management on GPGPU
This section presents a simple network with 3 nodes that is shown in figure 4.2. This figure
allows us to explain the memory organization for the communication algorithms which run on
GPGPU.
Figure 4.2: A simple net with 3 connected nodes
Each node is presented as a single processing element on GPGPU with bidirectional channels to
the other nodes. There are two main components for mapping graphs to GPGPU memory: State
and Communication links.
Node status are specified as a formal record having representations as C structures inside
GPGPU memory. These records are private for each node so they are not supposed to be reached
directly by the other nodes. Different with Occam simulation, using the shared communication
memory to send and receive messages to and from neighbours. Inside the message, there are
the information about node’s status which are recorded on GPGPU memory. These channels are
descriptors providing neighbour index, channel index, and buffers (more details in [27, 29]).
There are two main states in management the shared memory for data transaction in the
simulation. Firstly, the initial state, in which there is no connection between the satellite and the
sensor network. Secondly, the dynamic state, when the satellite has connection at least one node
in network, memory location will be expanded for satellite as a dynamic node.
Initial, the satellite has not appeared yet or there is no connection with nodes in network
field. Therefore, the communication can be described by a 2D table of size (NumberOfNodes +
32
CHAPTER 4. MEMORY MANAGEMENT AND SIMULATION ON GPGPU
NumberOfMobiles)×MaxFanOut. MaxFanOut is the sum of the maximum observed for node
fan-outs, plus the maximum permitted for the fan-out of node to mobiles. As an result, this
structure can cover all the needs for inter-communication of sensor network. With the network in
figure 4.2, it shows a data management in figure 4.3 with a provision for two mobile slots.
Figure 4.3: Initial state of communication manager without satellite communication
Communications between satellite and fixed nodes are handled in a Single Instruction Multiple
Devices - SIMD mode by an automaton interpreting communication descriptors. A static loop
is executed in parallel with up to MaxFanOut steps. However a local validation of transfers is
observed based on the local number of channels. Hence, transfers are concurrent copy from each
node’s local memory to the shared remote buffers.
According to the global communication activities, the synchronous model of processing on
GPGPU can resume:
• Nodes (reader) read data or correspond nodes from input buffers in shared memory.
• Node changes its status in private memory.
• Nodes (writer) writes data into output buffers in shared memory.
When a satellite enters (or leaves) the sensor network, the channel communication in figure
4.3 needs to be updated either for the mobile and for static nodes. The external scheduler follows
the mobile position along its path, and compute new connectivity for each significant move by
comparing this position to neighbour candidates (more details in [24]). After this computation,
an update of the network model takes place, and then the description table for communication is
modified in figure 4.4.
33
CHAPTER 4. MEMORY MANAGEMENT AND SIMULATION ON GPGPU
Figure 4.4: Dynamic state of communication manager with satellite communication appears
The main fact is then the possibility of messages to transfer from the static network to the
mobile, and the mobile sends back the message to static network. This communication occurs as
soon as possible just after network updates. An illustration is a distributed algorithm to compute
an approximation of the covered communication zone among the nodes and the satellite. This
illustration are presented before by the three algorithm protocols, in chapter ??.
4.3 Data transaction in communication protocols
In simulation on GPGPU, the communication protocols as the three proposed algorithms can
be done by the data exchange model which is illustrated in figure 4.5.
Figure 4.5: Data transaction between GPGPU and CPU for protocol algorithms
According to this model, there are 4 critical steps should be executed in high speed to return
the global result of the protocol algorithms under the constraints of study cases.
• Step S1: CPU Ram copy the data or a part of data necessary for computation to the memory
of GPGPU.
• Step S2: GPGPU computes the protocol algorithm with the copied data in memory.
• Step S3: GPGPU copy back the global result to CPU.
34
CHAPTER 4. MEMORY MANAGEMENT AND SIMULATION ON GPGPU
• Step S4: CPU displays the final result on simulation interface or the on-fly result on an
internal debugger.
4.4 Execution management controller the simulation with
NetGen
The critical problem in simulation of distributed algorithms on GPGPU is tracking and man-
aging the data transaction between the processes. Thus, the controllers are presented at high level
to track the process status in real time. In addition, to check system efficiency and correctness,
it should follow the real time progresses observing predicted effects on the global system repre-
sentation. As result, there are two approaches in control the result of algorithms on simulation:
Simulation interface and on Debugger Interface.
Simulation interface for global result of communication protocol In first approach, the
data transaction will follow the figure 4.5 by the order: S1, S2, S3, S4. Thus, we observe the
updating of final result each time the satellite moves in the simulation interface, see figure 4.6.
Obviously, with this case, there is no interaction between simulation and user. As a result, the
advantage of this approach is to help us easier to track the communication activities as well as the
change of network topology with the appearance of dynamic node (satellite).
Figure 4.6: Simulation interface at high level control
Debug interface for fly-on result of communication protocol Following the figure 4.5, the
work flow can be described by: S1, S2, S3, S4 (First topology update), S1, S2, S3, S4 (Second
topology update) . . . S1, S2, S3, S4 (Last result of topology).
Thus, we propose an internal debugger for process management on Cuda, which is developed
in SmallTalk environment, allows to observe the result S4 on fly. The simulation progresses can be
observed on high level through the node’s local result, global result, satellite position... The result
can be executed in real time, stop, reset or step by step. Moreover, the ability in moving to the
35
CHAPTER 4. MEMORY MANAGEMENT AND SIMULATION ON GPGPU
specified stage in execution of simulation to explore the data is supported also in this debugger,
see figure 4.7. As consequence, this approach allow us to observe well the data transaction between
nodes and the updating of global result of distributed algorithm.
Figure 4.7: Debugger interface at high level control
4.5 Simulation experiment on GPGPU
Code structure The final CUDA code is distributed into few files related to the CPU and
GPGPU behaviour description. The generated file from NetGen includes the communication de-
scription table. The development system used is a variant of SmallTalk that supports greatly
parsing and external access to dynamically linked libraries [31]. Thus, a simple call to the make
facility is enough to regenerate the library for a given network, and rebind to the running virtual
machine. After that, the procedures available in the library allow to control execution in various
ways, to extract, modify, or inspect node states, to pass variables and extract results.
Simulation environment The simulation is running on Linux machines with NVIDIA graphics
card (GeForce GTX480 and GFX680[32]). These cards provide respectively, roughly, 500 and 1500
processing elements. Both machines are equipped with Intel(R) i7 processors. Both CUDA system
and SmallTalk environment have great debugger and profiling tools. Nvprof NVIDIA profiling tool
is particularly efficient at understanding cost of data moves to/from the GPGPU.
Measures Simulation have been run on both the GTX480 and GFX680 GPGPU for problems
of significant size. Problems imply a visit of a satellite over random set of sensor (gateways). The
random set corresponds to a random distribution in a regular surface selected on QuickMap. This
way,wide area such as deserts, polar regions, countries or oceans could be virtually investigated. For
each set, the distributed simulation begins by producing the actual number of connected sensors,
likely to contribute to ground collective computations. Then leaders are elected,and the number of
different leaders provide the number of isolated sub-networks. By observing the maximum fan-out,
the simulation provide an additional information on the credibility of the network connectivity
36
CHAPTER 4. MEMORY MANAGEMENT AND SIMULATION ON GPGPU
(bound to sensor density and communication range). Finally the execution time provides an idea
on what can happen in long simulations (several orbits over the earth). Here the satellite path
is controlled from GPredict runs with a period of 1 second, during 15 minutes and based on the
anticipated algorithm (see table 4.1 and 4.2)
Number Sensors 100 200 400 600
Real Participants 91 186 331 434
Number of Networks 17 19 69 123
Max fanout 6 7 6 7
Execution time (s) 70.8201 199.772 221.243 263.062
Table 4.1: Results on GTX480
Number Sensors 100 200 400 600
Real Participants 91 186 331 434
Number of Networks 17 19 69 123
Max fanout 6 7 6 7
Execution time (s) 52.8619 143.016 467.402 688.439
Table 4.2: Results on GFX680
Evaluation The simulation of Anticipated algorithm works correctly and reliable. With sim-
ulation, the user can keep track in realtime for the interaction between Satellite and WSN. The
execution time of simulation depends on the number of sensor nodes in random network. In fact,
the execution time of simulation is effected also by the network topology on QuickMap.
4.6 Conclusion
On GPGPU, the node (process element) communicates to the others by the shared memory
channel. The data structure for communication is dynamic and can be updated with the appearance
of a mobile node. According to this memory management, the data transaction in computation
between GPU and CPU is described. With support from high level control execution managers,
the data communication on GPGPU can be tracked and observed in real time. Last, the GPGPU
simulation experiment is presented with various environment. As a result, the time execution of
anticipated algorithm is implemented and measured on several GPGPU.
37
5
Discussion and conclusion
In this chapter, the work is concluded and future plan is presented. Next, the research con-
tribution are presented. Finally, limitation of the work and possible future extensions are
described respectively.
5.1 MiCas project contribution
• An interface in generating and modeling the communication between mobile and sensor fields.
• The automatically network generator which supports well both in Occam and in Cuda.
• The reliable and adaptable data transaction protocols between mobile and sensor fields.
• The simulation with high performance speed in computing the global results on GPGPU.
• An internal Cuda debugger interface to manage the communication data between the nodes
as well as the local computing in the simulation.
5.2 Limitation
• The computing performance and power consumption of network depends on topology. There-
fore, we need a reliable network for various scenario tests.
• The GPGPU simulation is implement and measurement for anticipated algorithm only. The
transaction algorithm and flow algorithm are now in developing and implementing.
• We need a large set of test scenario instead of using a small set to evaluate the computing
performance as well as the power consumption of protocol algorithms.
5.3 Future works
• The first future work is to apply these protocol algorithms in simulation for various specified
study case, i.e Cricket flow in Senegal, Rice field controlling in Mekong delta.
38
CHAPTER 5. DISCUSSION AND CONCLUSION
• The second future work is building a real data transaction between the ground station (i.e
IC9100) and satellite. We can implement their communication in real time on simulation
framework with some experiences in signal processing and telecommunication.
• We also propose is an upgrading the modeling and simulation for the radio transmission
range from 2 dimensions to 3 dimensions. Obviously, the radio transmission range is an
uncompleted sphere in 3 dimensions because of the obstacles.
• A potential approach is propose a time-event scheduler to manage the data transaction
between satellite and sensor fields. Moreover, we can run the simulation as playing frame by
frame on video (identified by started time and end time of data transaction).
39
A
Appendix
A.1 VisualWork
VisualWork [33] is a cross-platform implementation of the Smalltalk language. The tool is
used for cross-platform development project. In our project, we work with VisualWorks on Linux
operating system.
A.2 Text Editor (gedit)
Text Editor (gedit) is the default GUI text editor in the Ubuntu operating system [34]. We use
this tool to develop the algorithm protocols in Occam and Cuda.
A.3 Command line profiler nvprof
nvprof is a light weight command-line profiler available for Linux and others operating system
[35]. This tool is very useful in measurement the details in time execution of simulation on GPGPU.
A.4 Algorithm and simulation implementation
The implementation of the work in the project, at the moment the report is written, can be
found at the address below.
http://wsn.univ-brest.fr/svn/CudaInterface/
and http://wsn.univ-brest.fr/svn/OccamAlgorithm.
or the simulation video: http://wsn.univ-brest.fr/QuickMap/Simulation.mov
A.5 Research contributions
Bernard Pottier, Pierre-Yves Lucas, Nguyen Huu Van Long, IRD/Bondy, Paris. RESSAC’S
2014, Global warming, global sharing, a case for micro satellites and sensor networks.
40
Bibliography
[1] N. Celandroni, E. Ferro, A. Gotta, G. Oligeri, C. Roseti, M. Luglio, I. Bisio, M. Cello, F. Davoli,
A. D. Panagopoulos, M. Poulakis, S. Vassaki, T. De Cola, M. A. Marchitti, Y. F. Hu, P. Pillai,
S. Verma, K. Xu, G. Acar, A survey of architectures and scenarios in satellite-based wireless sensor
networks: system design aspects, International Journal of Satellite Communications and Networking
31 (1) (2013) 1–38.
URL http://dx.doi.org/10.1002/sat.1019
[2] P.-Y. L. Bernard Pottier, Netgen: objectives, installation, use and programming, Tech. rep. (August
2014).
URL https://github.com/NetGenProject/documentation/blob/master/DocNetGen.pdf
[3] N. Lynch, Distributed Algorithms, Morgan Kaufmann, San Mateo, USA, 1996.
[4] Network topology wikipedia, http://en.wikipedia.org/wiki/Network_topology.
[5] Wireless sensor network wikipedia, http://en.wikipedia.org/wiki/Wireless_sensor_network.
[6] Sensors wikipedia, http://en.wikipedia.org/wiki/Sensor.
[7] N. John Markoff, Can’t find a parking spot? check smartphone,
http://www.nytimes.com/2008/07/12/business/12newpark.html, 2008.
[8] H. Heidt, J. Puig-Suari, A. Moore, S. Nakasuka, R. Twiggs, Cubesat: A new generation of picosatellite
for education and industry low-cost space experimentation, Proceedings of the AIAA/USU Conference
on Small Satellites, 2000.
[9] Q. Project, https://qb50.eu.
[10] Outernet/trendone.com, The outernet, say hello to the wild world web!, http://www.trendone.com/
outernet_english.pdf https://www.outernet.is/.
[11] P. Welch, F. Barnes, Communicating mobile processes: introducing occam-pi, Springer Verlag, 2005,
pp. 175–210.
[12] A. Iqbal, B. Pottier, Meta-Simulation of Large WSN on Multi-core Computers, DEVS10, in SpringSim
SCS Conference, Orlando, USA, 2010.
[13] A. A. (UBO), Simulation and modeling of physical evolutions by cellular automata, Tech. rep. (2013).
[14] P.-Y. Lucas, Modelisation, simulation, et synthese pour les reseaux de capteurs sans fil. une approche
synchrone., Tech. rep. (June 2014).
URL http://wsn.univ-brest.fr/svn/these-py/
41
BIBLIOGRAPHY
[15] G. project, http://gpredict.oz9aec.net/.
[16] ARGOS, http://www.argos-system.org/manual/.
[17] Iridium, http://iridium.com/default.aspx.
[18] G. S. Communications, http://www.globalsatellitecommunications.com/iridium/network.html#
sthash.vc3arrRL.dpuf.
[19] D. M. David Meldrum, O. Peppe, Developments in satellite communication systems, Tech. rep. (2001).
[20] L. E. orbit wikipedia, http://en.wikipedia.org/wiki/Low_Earth_orbit.
[21] R. of Cubesats in Space Industry, http://www.diyspaceexploration.com/cubesats-are-
revolutionizing-the-space-industry.
[22] C. techonologies, http://en.wikipedia.org/wiki/CubeSat.
[23] Zigbee/802.15.4 wikipedia, http://en.wikipedia.org/wiki/ZigBee.
[24] N. M. Guillaume Kremer, Mobility and synchronization in wireless sensor networks, Tech. rep.
(Febuary 2010).
URL http://wsn.univ-brest.fr/TER-rapports/KremerMelot.pdf
[25] Smalltalk wikipedia, http://en.wikipedia.org/wiki/Smalltalk.
[26] Occam compiler, http://projects.cs.kent.ac.uk/projet.
[27] H. Dutta, T. Failler, N. Melot, B. Pottier, S. Stinckwich, An execution flow for dynamic concurrent
systems: simulation of WSN on a Smalltalk/CUDA environment, DYROS/SIMPAR 2010, Darmstadt,
2010.
[28] Cuda c programming guide, http://docs.nvidia.com/cuda/cuda-c-programming-guide/
#axzz3Er0GIthS.
[29] T. Failler, Netgen : un generateur de code pour cuda principes, implementation et performances,
Tech. rep. (June 2010).
URL http://wsn.univ-brest.fr/TER-rapports/TERThibaultFailler.pdf
[30] P.-Y. Lucas, Etude de transmission radio avec tvm et xbee, Tech. rep. (Febuary 2012).
URL http://wsn.univ-brest.fr/~pyves/xbee_et_tvm_v2.pdf
[31] C. corporation, Dll and c connect.
[32] Nvidia, Nvidia geforce gtx 680, http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-
680-Whitepaper-FINAL.pdf (2011).
[33] VisualWorks, http://www.cincomsmalltalk.com/main/products/visualworks/.
[34] T. Editor, https://help.ubuntu.com/community/gedit.
[35] C. profiling tool, http://docs.nvidia.com/cuda/profiler-users-guide/#axzz3E69URRZs.
[36] N. CUDA, https://developer.nvidia.com/cuda-zone.
42