Wireless Sensor Network to Satellite Interface.

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


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


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


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


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


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


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


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


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


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


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.


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


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


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 :


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


nextState := StateReceiveParent

Node go to this idle state after propagating the request (if possible) and asking for the parent

StateEnd :


nextState := StateEnd

19


Upward result sending back

In figure 3.4 describes the automation management of upward.

Figure 3.4: Automation management for upward propagation


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 :


nextState := StateIdle

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


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


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.


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


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


to the following patterns.

23


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


Set (BufOut[indexParentOfTree2], SendResult)


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


Set (BufOut[indexParentOfTree2], SendResult)


ELSE

Set(BufOut[all],NULL)

After forwarding result, the node comes to idle state, the state StateSendResult.

StateSendResult :



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


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


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


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


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


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


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


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


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


• 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


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


(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

http://dx.doi.org/10.1002/sat.1019

https://github.com/NetGenProject/documentation/blob/master/DocNetGen.pdf

http://en.wikipedia.org/wiki/Network_topology

http://en.wikipedia.org/wiki/Wireless_sensor_network

http://en.wikipedia.org/wiki/Sensor

https://qb50.eu

http://www.trendone.com/outernet_english.pdf

http://www.trendone.com/outernet_english.pdf

https://www.outernet.is/

http://wsn.univ-brest.fr/svn/these-py/

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

http://gpredict.oz9aec.net/

http://www.argos-system.org/manual/

http://iridium.com/default.aspx

http://www.globalsatellitecommunications.com/iridium/network.html#sthash.vc3arrRL.dpuf

http://www.globalsatellitecommunications.com/iridium/network.html#sthash.vc3arrRL.dpuf

http://en.wikipedia.org/wiki/Low_Earth_orbit

http://www.diyspaceexploration.com/cubesats-are-revolutionizing-the-space-industry

http://www.diyspaceexploration.com/cubesats-are-revolutionizing-the-space-industry

http://en.wikipedia.org/wiki/CubeSat

http://en.wikipedia.org/wiki/ZigBee

http://wsn.univ-brest.fr/TER-rapports/KremerMelot.pdf

http://en.wikipedia.org/wiki/Smalltalk

http://projects.cs.kent.ac.uk/projet

http://docs.nvidia.com/cuda/cuda-c-programming-guide/#axzz3Er0GIthS

http://docs.nvidia.com/cuda/cuda-c-programming-guide/#axzz3Er0GIthS

http://wsn.univ-brest.fr/TER-rapports/TERThibaultFailler.pdf

http://wsn.univ-brest.fr/~pyves/xbee_et_tvm_v2.pdf

http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf

http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf

http://www.cincomsmalltalk.com/main/products/visualworks/

https://help.ubuntu.com/community/gedit

http://docs.nvidia.com/cuda/profiler-users-guide/#axzz3E69URRZs

https://developer.nvidia.com/cuda-zone

Wireless Sensor Network to Satellite Interface.

Documents