RobAIR2013-RICM4-Groupe1-Suivi

the Team

This team is composed of two 4th year Polytech Grenoble students, in System & Networks specialty.

The members of this team are Alexandre Corso and Laurène Guelorget.

Project objectives

Our project is a part of the RobAIR2013 project.

The shared project

RobAIR is a project in which several schools and departments are involved, such as:

• the RICM and 3I departments of Polytech'Grenoble
• ENSIMAG
• Pole Design de Villefontaine

This project consists of developing an extensible and open-source robotic platform. The robot, called RobAIR, is a telepresence robot that can be used for museum tours while the user controls it thanks to an Android tablet.

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.

WEEK 1: from January 14th to January 20th

• We discovered the project and the different objectives.

WEEK 2: from January 21st to January 27th

• We organized a meeting with the 3I4 and RICM4 students. During this meeting, we talked about what everyone understood of this project and what everyone's objectives are.
• We met with the three students from Pole Design de Villefontaine and they told us what they have been working on for the last month.
• Meeting with Rémi Barraquand at INRIA to talk about ROS.

WEEK 3: from January 28th to February 3rd

• Writing of the SRS (first draft)
• Talk with Thomas Calmant and Joao Claudio Américo who worked on RobAIR before with Didier Donsez

WEEK 4: from January 4th to February 10th

• Meeting with the RICM5 working on this project
• Talk about the different options to use to implement the roaming. We decided to use the Multipath TCP protocol and we started to study this protocol.

WEEK 5: from February 11th to February 17th

• Comparison tests between the latency when disabling an interface with TCP and MPTCP.
• We updated our SRS to its final version.

WEEK 6: from February 18th to February 24th

• We received 2 wifi cards and tested them.
• We created the UML page for the project.

WEEK 7: from February 25th to March 3rd

~ Holidays

WEEK 8: from March 4th to March 10th

• We are writing a script to scan and search for available networks (in C language):

- First we scan the network

- Then, we order the available list of networks by signal strenght

- Next, we compare the SSIDs to a database of past used networks

- Finally, we connect the robot to the network

WEEK 9: from March 11th to March 17th

• We installed WAMP and created a database with PhpMySQL
• Program that put the ssid, password and signal strenght in a file

WEEK 10: from March 18th to March 24th

• Parsing of a file to get the different data concerning a network

WEEK 11: from March 25th to March 31st

• working on the roaming software
• helping build the robot (configuration 2) with Didier Donsez

WEEK 12: from April 1st to April 7th

~ Easter

WEEK 13: from April 8th to April 14th

• finishing the program
• preparation of the presentation
• writing of the report
• making the flyer

Related documents

• The Software Requirements Specification (SRS) can be found here.
• The UML of this project can be found here.
• The global project's page can be found here.

• The pdf of the presentation (RobAIR2013): presentation_general.pdf
• The pdf of the presentation (WiFi roaming): presentation_roaming.pdf
• The report: rapport_roaming.pdf
• The Flyer of the project (RobAIR2013): flyer_general.pdf
• The Flyer of the sub-project (WiFi roaming): flyer_roaming.pdf
• The source code: Sources.tar