Deployment of a Sensor Network : Différence entre versions

De Ensiwiki
Aller à : navigation, rechercher
(Authors)
Ligne 141 : Ligne 141 :
 
|-
 
|-
 
| align='center' width="25%" |'''Tutors'''
 
| align='center' width="25%" |'''Tutors'''
| align='center' width="75%" |[mailto:franck.rousseau@imag.fr Frank Rousseau], [mailto:etienne.duble@imag.fr Etienne Dublé]
+
| align='center' width="75%" |[mailto:franck.rousseau@imag.fr Franck Rousseau], [mailto:etienne.duble@imag.fr Etienne Dublé]
 
|-
 
|-
 
| align='center' width="25%" |'''Institution'''
 
| align='center' width="25%" |'''Institution'''

Version du 12 mai 2016 à 12:28

Mycomputer.png  Deuxième Année  CDROM.png  Informatique 


Project schedule.png
Titre du projet Deployment of a Sensor Network
Cadre Projets de spécialité

Encadrants Franck Rousseau, Etienne Dublé


NB: this page is just a draft because we are presently doing this project. It will end June the 15th 2012.

During the 2nd year at Grenoble INP-ENSIMAG, students are asked to realize a project in group of about four students, supervized by tutors (teachers, researchers, etc). Our group composed of two students in Telecommunications (Mouhamed Soumaré and Thomas-Elliot Tollardo) and a student in Embedded Systems and Software (Julien Vipret) has chosen the topic of Sensor Networks.

Introduction

Figure 1. Topology of our Sensor Network

The sensors used during this project are MB851 sensors based on STM32W and supplied by STMicroelectronics. A sensor is a device that converts a physical quantity (electromagnetic wave, temperature, pressure) into a another quantity that can be exploited, by a computer system for instance.


For our experimentations, a network of such sensors is deployed. There are three main elements in this network.

  • the sensors that communicate between them using a wireless protocol.
  • the node which is the computer linked to the sensor with a serial connection. It gathers all the datas received by the sensor and sends them to the controller.
  • the controller which is the central computer that monitors the whole sensor network. It sets the parameters of each sensor and launchs the scenario defined by the user.


On Figure 1 opposite, we can see the topology of our sensor network.

Thus, the goal of the project is to develop an environment of study for the Sensor Networks. This environment aim is to validate or refute the current work being done on the topic by researchers. This page describes the different tasks that this environment is able to do. It was a really interesting experience for our team which immersed us in the world of research with its issues, its challenges and its constraints. This will lead for two of us to an internship at STMicroelectronics in the same field.


Connections

to the nodes

The user from the controller must be able to connect to the different nodes of the network.

For that, two different connections are established :


  • A SSH connection initialized by the controller is used to send commands to the nodes. This connection is used as a management channel.
  • Another TCP connection is used to send the datas gathered by the nodes to the controller. The datas are sent as they are received from the sensor. They are only analyzed and handled by the controller.

to the sensor

A connected sensor emulates a serial port at the level of the node. Many means can be used by a node to listen to its emulated serial port :

  • the tool serialdump, implemented by senslab
  • the python library pySerial
  • the tool from the twisted framework SerialPort
  • other basic tools such as minicom or cat

In the project the tool serialdump is used. It prints in the standard output the datas read from the emulated serial port.

On the Figure 2 below there are all the connections set up in our network.

Figure 1. Connections in our Sensor Network

Flashing the sensor

Once a connection is established with each node it is possible to manipulate the sensors as needed.

Within the sensors is implemented a small, opensource and multitasking operating system called Contiki. This operating system is very well-adapted for embedded systems such as sensors.

In order to determinate the behaviour of a sensor, a micro-software called firmware is installed on it. The process of installing the firmware in the sensor is called flash and is realized by a software called flasher supplied in our project by STMicroelectronics.

For the project we developped different kind of firmwares.

  • A PAN firmware
  • A non-PAN firmware

Sensors flashed with a PAN or Non-PAN firmware use a specific routing protocol (LOADng) being implemented by researchers from the LIG. A sensor flashed with a PAN firmware has the same bahaviour as a border router/gateway. Usually, only one is used by experiment. Such a sensor broadcasts packets called beacons to first let other sensors coordinate with it and secondly to exchange datas with them. A sensor flashed with a non-PAN firmware listens to the beacons in order to coordinate with a PAN and then exchange datas with it.

Other firmwares already implemented were also used to test or to diversify the scenarios of our experimentations.

  • A UDP-Client firmware that sends datas to a defined sensor flashed with a UDP-Server firmware.
  • A UDP-Server firmware that receives datas from any sensor flashed with a UDP-Client firmware.
  • A sniffer firmware that is able to collect all the packets encapsulated in a 802.15.4 frame.
  • A Hello-Word firmware that does not use the network protocols but just print the MAC Address of the sensor and the famous "Hello Word" when the reset button of the sensor is pushed.


Using the flasher from STMicroelectronics, the sensors are flashed with the appropriated version of the contiki firmware. To be more efficient, the different sensors are flashed in parallel using pipes established with the SSH connections. In the python program the user launchs, he can specify which firmware he wants to use for each node.


Gathering information from the nodes

The first part of the project consists in finding some ways to collect informations from the nodes linked to the sensors. The user defines a scenario to play in which he specifies all the comands that the controler will send to each node. He can see the evolution of the scenario not only on the standard output but also on a web interface or on wireshark.

Forwarding to the controler

A TCP server on the controler listens on a defined port. Each node is therefore able to send data to the controller using sockets. In order to parse the datas received by the controller each nodes prefixes its datas with a special character and the number of the node.

Parsing and utilization of the datas

Once all the informations datas are received by the controller, they are parsed to know which node has sent them and then traited in different ways.

  • the datas received by the controller can be directly displayed on the standard output.
  • they can be displayed using the free packet analyzer Wireshark.
  • a graph-shaped topology can be observed in a web interface.

Wireshark

The serial port of the sensors flashed with the sniff firmware, releases datas encapsulated in a "slip" layer. This kind of layer is just used to know easily the end of each frame.

With the tool slip2pcap implemented by Etienne Dublé, this "slip" layer is converted into a pcap layer that can be read by Wireshark. The conversion slip to pcap is done on the controller.

These datas converted to pcap can be easily displayed on Wireshark.

Figure 1. Launching Wireshark from the program

The web interface

A web interface was implemented in order to display a graph-shaped topology of the network.

When the sensors are flashed with PAN or non-PAN firmwares this graph allows to see in real-time how the sensors discover between them.

Figure 1. Topology of our Sensor Network


Exprimentations

Once the environment was implemented different experimentations were realized in order to test the environment.

  • influence of the emission power of the sensors
  • interferences with the 802.11: use the 26th channel?

TODO: improvements

To allow other students to correct and complete our work, we wrote a user documentation. Here is a non-exhaustive list of what we think could have been rapidly implemented with more time:

  • with a python module, be able to know which serial port is used (ttyACM0, ttyACM1...) and though connect several sensors to a node
  • real-time tree which describes the topology of the network
  • include the date in the parsed packet collected in the controler

Authors

2012 2nd Year Speciality Project: Deployment of a Sensor network
Speciality Project 2012 Experimentations in a Sensor Network
Team Mouhamed Soumaré, Thomas-Elliot Tollardo, Julien Vipret
Tutors Franck Rousseau, Etienne Dublé
Institution Grenoble INP -- Ensimag
Date May 21st -June 15th 2012
  • Oral presentation slides

Slides

  • User documentation

User documentation