(→Some ideas to improve the UMOBILE Lab) |
(→Possible evolutions) |
||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | 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. | |
| − | + | ||
| − | + | == Current lab status == | |
| − | + | The UMOBILE researchers can login and access the lab [[UMOBILE_Lab#L2TP_remote_access | 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. Each SEG runs the UMOBILE software image and is ready to be configured and connected to other SEGs, through NDN (is NDN the right attribute?) 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. | |
| + | == Possible evolutions == | ||
| + | === UMOBILE Lab and Named Data Networking Testbed === | ||
| + | There is an NDN node in the lab (the ''first node'') that is reachable from the internet. This node could be connected to the [https://named-data.net/ndn-testbed/ 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; | ||
| + | COPELABS is connected 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. | ||
| − | + | === Experiments and Dashboards === | |
| − | + | 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 [https://www.iot-lab.info/tools/ 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: | |
| + | * The best way would be to allow the app interface to be remotely exported, allowing the remote research to set up the app. | ||
| + | * The plan B would be for the remote experimenter to set up the app usage by command line. This would require the app to provide a remoteAPI with a set of calls that have to be made available in the UMOBILE Lab portal. For instance in the case of Now@ this would mean: | ||
| + | ** to setup interests, | ||
| + | ** to generate local data (to be uploaded remotely to the local node), | ||
| + | ** to get notifications about the reception of data, | ||
| + | ** to get information about the status of the application. | ||
| − | + | 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
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. Each SEG runs the UMOBILE software image and is ready to be configured and connected to other SEGs, through NDN (is NDN the right attribute?) 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.
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; COPELABS is connected 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.