qMp (Quick Mesh Project) - Packages

h1. Mobility performance Evaluation of Mesh rOuting protocols (MEMO)

Experimentation Project executed by "RouteK S.L.":http://routek.net as part of "Federation for FIRE (Fed4Fire)":http://www.fed4fire.eu integrated project and funded as "Innovative Experiments by SMEs Fed4FIRE-SME-1":http://www.fed4fire.eu/open-calls/1st-call-for-sme-closed.html

h2. Project Summary

In contrast to traditional IP-mobility solutions (like MIPv6), which require a pre-deployed infrastructure and are limited to the coverage range of the core-backbone nodes, a fully mesh-based solution can conceptually provide a self-organized network that does not require any pre-deployed infrastructure and which’s coverage expands as nodes participate in the network. However, the performance of mesh networks in the presence of mobile mesh nodes is unclear.

This project focuses, from an experimental point of view, on the capabilities of several mesh routing protocols (Babel, BMX6, BATMAN-adv, OLSR, and IEEE802.11s) for supporting mobile mesh nodes. These investigations are of significant interest because the demand for seamless mobility has become imperative for the users.

Related experiments will be prepared using "emulab - total network testbed":http://www.wall2.ilabt.iminds.be/ and executed in w-iLab.t Zwijnaarde (iMinds) and Community-lab (UPC) Fed4FIRE testbeds because both of them support the configuration of wireless nodes similar to our standard deployments and are suitable to perform mobility tests. 

h2. Concept and objectives

The main question we are seeking to answer with this experiment is (i) if and to what extend traditional IP-mobility solutions for wireless networks (like MIPv6) can be substituted with full-mesh based solutions and (ii) to what extend the existence of mobile nodes, and thereby introduced temporary and highly dynamic links, affects the end-to-end performance of stationary nodes.

To answer this question, the objective of this proposal is to analyze state-of-the-art routing protocol solutions regarding their capabilities for supporting topology dynamics caused by mobile mesh nodes. 

The mobility support will be measured by means of the maximum amount of topology changes a protocol can handle while maintaining a continuous connection between (i) a mobile node and a stationary destination node and (ii) two stationary nodes which's possible end-to-end path include links via a mobile node. 

The exact metric for ranking the mobility performance of a protocol is given by a reference experiments. In addition, relevant cost factors for achieving an identified mobility performance will be captured as needed for providing a fair analysis of each's protocol advantages and disadvantages.

The main objective of our concluding analysis is to provide benchmarking results and guidelines that allow to estimate and predict to some extend the feasibility for supporting a given use case with a particular routing protocol.

h2. Outlook

The project execution will officially start by June 1st and end by September 30 2014

This wiki will be updated over time.

h2. Feedback and findings on F4F API, federation, usage, and documentation

The first contact following the suggested "intros":http://doc.fed4fire.eu/ , "tutorial":http://doc.fed4fire.eu/firstexperiment.html , "jFed":http://fed4fire-testbeds.ilabt.iminds.be/jfed-documentation/ and "ilabt":http://fed4fire-testbeds.ilabt.iminds.be/ilabt-documentation/ documentations yield to instant success. Within few hours it was possible to pass the registration procedure and successfully execute a simple experiment with two unbound wireless nodes in the w-ilab.t testbed, showing 

reasonable ping latencies and losses depending on configured transmit power. Congratulation for the good integration and documentation.

During a first kick-off teleconference with our mentors further (more advanced) issued were identified and discussed. These issues as well as their temporary solutions (and possible later issues as will likely be encountered during the project) are collected for concluding feedback in the following.

h3. Federation of accounts and required registrations

Some minor confusion raised due to different existing registration portals and domains.

* "emulab":http://www.emulab.net represents kind of reference portal but is not needed for F4F participation. Emulab-based experiment specification use NS syntax and registration procedures of following (required) portals are based on this.

* "wall2":https://www.wall2.ilabt.iminds.be/ provides the recommended registration portal for F4F participation when using jFed and Rspecs API

* "wilab2":https://www.wilab2.ilabt.iminds.be registration is required for F4F participation in case of emulab (NS) experiment-specification API is preferred (although not suggested). A registration is also needed for reviewing the allocation table of specific (wireless) nodes and for exclusive slot-reservation of nodes for a F4F experiment. The federation of wall2 and wilab2 registration and resource reservation is planned.

h3. Using "OpenWRT":http://openwrt.org based node OS images

Due to the active wireless development and its optimizations for embedded wireless-router devices of "OpenWRT":http://openwrt.org based systems we are preferring OpenWrt based node images for our experiments

* The corresponding "documentation section":http://fed4fire-testbeds.ilabt.iminds.be/ilabt-documentation/urnsrspecs.html#install-a-specific-disk-image-on-a-node initially lacked comments on using OpenWRT. [FIXED]

* Documentation for preparing and deploying customized node images is provided only for "pcgen1 nodes":http://fed4fire-testbeds.ilabt.iminds.be/ilabt-documentation/tipsandtricks.html#using-custom-images-on-virtual-wall-1-pcgen1-nodes. [TBD]

Aiming for Zotac and OpenWRT nodes we agreed on the following procedure:

 * User prepares desired tar.gz image (using network configuration of already-provided openWRT images)

 * Requests further image testing and adaption via email to testbed admins for enabling them.

h3. Outband experimentation-data access

Documentation for "accessing experimentation data":http://fed4fire-testbeds.ilabt.iminds.be/ilabt-documentation/storage.html of inactive experiments lacked access description. The explained approach is:

* via central data login at: http://ops.wall2.ilabt.iminds.be

* navigating to: /groups/wall2-ilabt-iminds-be

h3. Documentation and procedure for exclusive registration of specific nodes for F4F wall2 testbed.

The agreed procedure is:

* Intro given in (currently "broken":http://10.11.31.5/status/tutorials/Emulab-Wilab.pdf ) "w-iLab.t documentation":https://www.wilab2.ilabt.iminds.be/index.php3?stayhome=1 [TBD...]

* Check node list (position,capabilities in (currently "broken":http://10.11.31.5/status/status.php ) in "w-iLab.t documentation":https://www.wilab2.ilabt.iminds.be/index.php3?stayhome=1 [TBD...]

* Check availability of nodes in allocation table using (wilab2 registration). Which URL exactly ?? [TBD...]

* Reserve desired nodes and allocation slot via private mail so they are blocked for others

* Define registered nodes via "RSpec":http://fed4fire-testbeds.ilabt.iminds.be/ilabt-documentation/urnsrspecs.html#request-rspecs-w-ilab-t or (graphical API node name). 

h3. Documentation on controlling wireless-mobile-node movements in w-iLab.t testbed 

The agreed procedure is:

* VPN access to private address space needed, VPN credentials requested via private mail

* Undocumented Graphical user interface for defining node movement [TBD...]