Le projet ECOM consiste à concevoir et développer une application de commerce électronique. Il est constitué de deux parties principales : la partie IHM et la partie Système, qui sont menées en parallèle pendant toute la durée du projet.

L'équipe

Le projet a débuté le 13 septembre 2013 et va durer environ 3 mois. L'équipe est formée de 4 membres de RICM5, deux de l'option Communication Multimédia et deux de l'option Systèmes et Réseaux. Nous nous sommes répartis les différents rôles en fonction de la spécialité et l'envie de chacun :

Chef de projet : Simon Planès
Auteur : Laurène Guelorget
Concepteur d'interaction : Lotfi Manseur
Experte en utilisabilité : Laurène Guelorget
Graphiste :} & Walid Bibi
Chef de développement : Lotfi Manseur
Développeurs : Toute l'équipe

Notre site

Our sub project objectives

We are responsible for the WiFi roaming:

Roaming ensures that at all time, the wireless device is kept connected to the network, without losing the connection.
For that, we decided to use the Multipath TCP Protocol because it offers better throughput and a smoother reaction to failures.
We wrote a program that ensures the WiFi roaming through 2 WiFi interfaces

WiFi roaming is a very important point concerning the project as we have to make sure that the robot stays connected at all time. RobAIR will be used in a museum where every room is likely to have its own WiFi Access Point. When the robot changes room, it has to stay connected, even as the change of Access Point is being made.

Technologies used

WiFi roaming

Roaming is a technology which allows a station to change his Access Point while remaining connected to the network. Roaming was not implemented in the WiFi standard, even though WiFi is a wireless technology. The reason is that WiFi exists since 1999 but at the time, wireless stations (such as laptops) were moved only when turned off. So contrarily to the GSM network, which included roaming from the start, roaming is not integrated to the WiFi technology.

Roaming process

In this figure, we can see how roaming will work in our project. Our robot possesses two interfaces (wlan0 and wlan1) and at all time, it is connected to at least one Access Point. First, the robot is connected to the Router1 on wlan0. By moving, the robot receives signals from other Access Points. The Router2's signal is stronger so the robot connects its free interface (in this example, wlan1) to Router2. It can then disconnect itself from the Router1 Access Point. This process goes on as the robot moves around.

Multipath Transmission Control Protocol

We decided to use the Multipath Transmission Control Protocol (shortened MPTCP) because it offers better throughput and a smoother reaction to failures. MPTCP adds the capability of simultaneously using multiple paths to a regular TCP session. The availability of multiple connection paths and the capability to dynamically schedule traffc between them allows more flexibility and efficiency in Internet congestion control. MPTCP is a standard in the pipeline at the Internet Engineering Task Force (IETF). The goal of this protocol is to use the same TCP connection hrough different network interfaces. One of the most typical use is to unload GSM networks via WiFi. It allows you to use WiFi on your Smartphone and as soon as you are not in range of WiFi, you swap to GSM 3G network. The main advantage of MPTCP is that the change of network is totally transparent for the applications. Even if the standard is in the pipeline, it is already possible to use MPTCP on a Linux distribution thanks to a modified version of the kernel. Hence, we had to recompile the kernel to be able to use MPTCP.

The functioning is similar to TCP. First, there is a handshake with the server, like with the classic TCP protocol. Only with MPTCP, the client sends a additional option that signals that it is capable to use MPTCP. The server has to respond with the same option for the communication to be enabled. The congestion management with MPTCP aims to have the throughput at least as good as the max throughput on the best interface. For that, a congestion window is kept for each path. After that, the congestion management is the same as in classic TCP.

Solution suggested

To ensure that the robot stays connected at all time, we wrote a program in language C and we created several data structures to manage the WiFi networks. This program of WiFi roaming will be executed on the Ubuntu tablet that will be on the robot.

global functioning of our program

Our program follows several steps:

First, the program scans and searches for all available networks in range thanks to the iwlist UNIX command. The command iwlist allows us to view lots of information about a wireless card and its connectivity. We use the scan option which is a privileged operation (root only). This option gives us the list of Access Points and Ad-Hoc cells in range, and information about them (such as the SSID, quality, frequency, type of encoding, etc.).
After that, the program puts the SSID, the quality of the signal (the signal strength) and the index (an ID number to identify the WiFi network) in a file.
Then, by parsing this file, the list of available networks are ordered by signal strength into a data structure.
Next, we compare the SSID to a database of past used and known networks to get the password for the WiFi network.
Finally, we connect the robot to the network.

This process is implemented into a loop and is repeated at regular time intervals. If a WiFi network scanned is not in the database, the process restart with a reduced time lapse. If one interface is already connected to a WiFi network, then we try to connect the other interface. In any other case, we connect the interfaces in turn, one after the other. We save the SSID of the network on which an interface is connected in a variable so that we can't connect an interface to a WiFi network already used by the other interface.

Progress of the project

The project started January 14th, 2013.

Sprint 1: du 24 septembre au 7 octobre

Compréhension du sujet
Rédaction du cahier des charges

Sprint 2: du 8 octobre au 21 octobre

Dossier de conception IHM (début)
etc.

Documents associés

Le cahier des charges (CDC) est disponible ici.
Le dossier de conception IHM
Le dossier de conception système
etc.

Ecom ricm5 groupe3

Contents