| Line 3: | Line 3: | ||
XXXX 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. | XXXX 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 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 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; the figure below represents the idea. | |
XXXX figure | XXXX figure | ||
| − | There is an NDN node in the lab (the ''first node'') that is exposed over the internet with a public IP address. 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 be reached from any other node of the NDN testbed; 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. | + | There is an NDN node in the lab (the ''first node'') that is exposed over the internet with a public IP address. 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 be reached from any other node of the NDN testbed; 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. |
== Experiments and Dashboards == | == Experiments and Dashboards == | ||
A useful and appealing lab should have clear dashboards and easy-to-configure parameters. As Paulo suggested some days ago, a good example of an on-line lab is the [https://www.iot-lab.info/tools/ FIT IoT-Lab]. | A useful and appealing lab should have clear dashboards and easy-to-configure parameters. As Paulo suggested some days ago, a good 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 ( | + | 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 dashboards should allow to browse the data structure of the different nodes; e.g. the FIB. Any significant data structures should be displayed. | ||
| Line 18: | Line 18: | ||
The results should be collected and measured through specific dashboards. | 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 the non-technical public what the demo is "''demonstrating''". | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The UMOBILE researchers can login and access the lab XXXX via VPN^ E CHE FANNO? prego spiegarlo.
XXXX 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 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 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; the figure below represents the idea.
XXXX figure
There is an NDN node in the lab (the first node) that is exposed over the internet with a public IP address. 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 be reached from any other node of the NDN testbed; 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.
A useful and appealing lab should have clear dashboards and easy-to-configure parameters. As Paulo suggested some days ago, a good 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 the non-technical public what the demo is "demonstrating".