The main goal of the lab is to test the outcomes of the project. At this stage of the project, this means to configure the lab in order to "map" the POC1 and POC2 scenarios; in other words, POC1 and POC2 become the first two experiments to carry out in the lab. A complete simulation of the POCs in the lab will definitely help our demonstration in Umbria.
The UMOBILE researchers can login and access the lab as explained here. Last week AFA has upgraded the SEG nodes, as requested by ATHENA/UCAM.
The UMOBILE Lab is mainly constituted of some Raspb PI, marked as SEG in the figure "UMOBILE testbed..."; at the moment the Mikrotik devices are just used as (IP) routing infrastructure. XXXXX Each SEG runs the UMOBILE software image and is NDN-connected to other SEGs, through NDN tunnels. The NDN tunnels lay over the IP layer; it is not considered an interesting option to modify the IP routing layer, in order to get modifications of the NDN layer. Instead it is possible to change the NDN topology changing the NDN routes/tunnels.
Although There is an NDN node in the lab (the first node) that is reachable from the internet. This node could be connected to the Named Data Networking Testbed, that already reaches the AFA Systems plant. Consequently every node of the UMOBILE Lab could reach any other node of the NDN testbed; This could allow to COPELABS is connected to to the NDN testbed, too: we expect it is possible to exchange (UMOBILE) messages between devices/apps at COPELABS Research Center with devices/apps at UMOBILE Lab. Conversely a user logged in the UMOBILE Lab can exchange messages with other NDN nodes in the NDN testbed.
When achieved the UMOBILE POCs simulations, it would be interesting to generalize the purpose of the lab. Here are some ideas circulated within the consortium and especially during last ACM ICN in Berlin.
A useful and appealing lab should have clear dashboards and easy-to-configure parameters. As Paulo suggested some days ago, an extensive example of an on-line lab is the FIT IoT-Lab.
Changing the parameters should change the configuration of the lab (including the topology of the NDN links) in order to run different experiments. A comfortable GUI should allow to set the parameters, as well to load n-uples of parameters with just one command.
The dashboards should allow to browse the data structure of the different nodes; e.g. the FIB. Any significant data structures should be displayed.
The results should be collected and measured through specific dashboards.
Each device and UMOBILE software image would have hooks (i.e. API) to set parameters and access the significant data structures.
In what concerns the applications in particular (Now@, Oi!, Router planner) (here copying Paulo's email), it seems that:
About the UMOBILE software image for the SEG (RaspB PI) we need a similar analysis, as well as about the UMOBILE routing components.
As a final consideration, some of the lab's dashboards (displayed on a big monitor) would be useful during the final demo to make clear to a non-technical public what the demo is "demonstrating".
An option is to open the lab to foreign (non-UMOBILE) researchers, stating which is the the expected appropriate usage of the lab in a guideline or a policy statement or a similar document.