stg-tud/bp2022_netlab

The repository provides software that creates configuration files for the BonnMotion, CORE, coreemu-lab and The ONE programmes from a single TOML file.

bp2022_netlab's Issues

Move Networks from NodeGroups to own data structure

output generation (coreemu-lab)

User Story

As a user I want to receive an output which is compatible to coreemu-lab, so that I can use that software in my workflow.

Description

As a user i want to have the opportunity to use coreemu-lab in my experiments for experimental reasons. I want to receive an output that is compatible with coreemu-lab.
This helps me to evaluate my experiments with the output data.

Acceptance criteria

• Generate config file/call parameters for coreemu-lab
• The output format is compatible with coreemu-lab
• output: all inserted parameters are correctly parsed

Simulation duration time

User Story

As a user, I want to be able to set the simulation time, so that I can experiments with different durations.

Description

As a user I want to set the simulation time, so that I can run different experiments for different lengths of time.
For each experiment I can set the simulation time seperately.
I am able to write the simulation time into the input file.

Acceptance criteria

• The simulation duration time is changable in the configuration file
• Processing of duration time to other tools

Random Seed

User Story

As a user I want the possibility to set a random seed, so that I can control all random events in my experiments.

Description

As a user, I want to have the possibility to have random seeds to create equal experiments.
This ensures the ability for me to track changes within the simulation.

As a user I want random seeds, so that the same thing always happens in every experiment with the same random events. I want to be able to have different random events and also be able to reproduce them.

Acceptance criteria

• Given random seeds are correctly passed to all generated config files
• If random numbers are generated by our software, those also depend deterministically on the given random seed
• If no random seed is given, a random seed should be generated and also dumped to output files
• Test results with same random seed equal

user interface

User Story

As a user I want to specify the TOML configuration to load, so that I can store configurations for different experiments.

Description

As a user I want to access and start the software via the console to avoid further steps for using it.
For me, this increases the efficiency and usability in the general workflow.

Acceptance Criteria

• The software can be started via the console
• The TOML file to load can be specified
• It can be specified whether DEBUG logging should be used
• It can be specified whether existing files should be overwritten (see #44)
• Useful help should be provided for the user on how to use the software and parameters

Documentation (end user & developers)

Single configuration file

User Story

As a user I want to specify my experiment in a single file so I can have it in one central place.

Description

I have the possibility to put all data in one TOML file to start a simulation.
I can reuse the data from the file for several runs.

Acceptance criteria

• Single TOML file for experiment configuration.
• Test results from manually created tests equal test results from automated experiment.

Tasks

• #30
• #2
• #10

Mobility configuration for CORE

configurable logging & reporting for tools

User Story

As a user I want to be sure that any logging data is correctly forwarded so that I have less effort while testing.

Description

As a user I am able to insert logging parameters in my configuration file that they are forwarded to the dependant systems automatically. This helps me to reduce my manual effort while testing.

Acceptance criteria

• Conspicuities are forwarded to further systems.
• There is an compatible output in the outputfile.
• I want to be able to configure the logging of used tools.

Use docker or user-definied BonnMotion executable

Structure for experiment data + example data for nodes and movement

• Go structure (struct, class, etc.) for experiment data
• hard coded example data for nodes, positions, movement
• Only as a example for output generation tasks

output generation (ns3)

User Story

As a user I want a ns3 container setup so that I have the opportunity to verify a different possibility of network topologies.

Description

As a user I want a ns3 container setup to experiment on an extensible network simulation platform.
This increases my usage in how packet data networks work and perform.

Acceptance criteria

• generate config file/call parameters for ns3
• output format is compatible with ns3
• output: the movements of nodegroups are the same

Define format and pre-commit hooks

support for ad-hoc generation via bonnmotion

User Story

As a user I need the support for ad-hoc generation via bonnmotion so that I can test different mobility patterns with bonnmotion.

Description

As user I am able to insert data for bonnmotion in the configuration file.
I am able to change this data for several experiments. I am able to save the configuration file seperatily.
Each dataset can be reused for several runs.

Acceptance criteria

• I am able to execute experiments with Bonnmotion
• Results from experiments with exactly the same input data remain the same

internal logging

User Story

As a user I want to be able to comprehend the steps taken to generate the configurations, so that I can identify unexpected behavior/results more easily.

Description

The process of the generation should be logged and issues/warnings/errors should be reported to the user.

Acceptance criteria

• All occuring errors are logged
• The log file is saved with the outputs
• The log level (e.g. DEBUG) can be configured

TOML file to load experiment data

Allow loading of a variable TOML file to fill current experiment structure with given data.

(see #1)

End-to-end tests & examples

Structure for output generators

Provide versionated config templates and ability to choose version

User Story

As a user I want to be able to generate configuration files for different versions of CORE, The ONE, etc., so that I can choose between different program versions for my experiment.

Description

As a user I want different templates for configurations, so that I can choose between different standarized networks.
This leverages the usage effect for me, because I don't start from scratch.

Acceptance criteria

• Version/template can be choosen in TOML file or by CLI parameter
• There is an template for every current version of CORE/coreemu-lab/the-one

execution of commands

User Story

As a user I want to configure the execution of different commands so that I can start my experiment.

Description

As a user I want to be able to configure different commands in my configuration file, such as the following to start my experiments with network topology properly:

• pre-startup (for multi runs)
• start (execution of experiment)
• finish (a full stop of the simulation)
• post-finish/ data collection (extraction of the output data)
• report (extraction of data from output file)

Acceptance criteria

• It is possible to change values from description in the configuration file.
• I am able to forward commands in the config file to external programs.
• Results of simulation remain the same as if tested manually.

node groups (mobility)

User Story

As a user I want different mobility options based on the node group to test the changes of node groups in their mobility patterns during experiments.

Description

Depending on the experiment, I am able to insert different mobility options into my configuration files.
The settings are stored in the config file.
This helps me to test various experiments and mobility concepts.

Acceptance criteria

• I can select one mobility option per node group in the config file

wireless interfaces

User Story

As a user I want configurable wireless interfaces so that I can test different wireless interfaces in my experiments.

Description

As a user, I want the ability to configure different wireless interfaces with following parameters.

The configuration consists of:

• name of interface
• range of interface
• bandwidth of interface
• delay
• packetloss

All criteria are relevant for me as a user to test different wireless networks throughouly in rergards to different network topology experiments.

Acceptance criteria

• Change of parameters in configuration file can be made
• Various specification of the paramater name, range, bandwith, delay and packetloss

output generation (bonnmotion)

User Story

As a user I want to be able to pass my configuration to BonnMotion, so that I can create movement patterns without extra effort.

Description

As a user i want to use BonnMotion in my experiments. To include BonnMotion in my experiments easily, I need to be able to include BonnMotion from my input file. Extracted data is compatible to be used in BonnMotion.

Acceptance criteria

• generate config file/call parameters for BonnMotion
• working/compatible BonnMotion file
• output: the movements of nodegroups are the same as if generated by hand
• config file/call parameters must be compatible with BonnMotion

Export output config template

User Story

As a user I want to export an output configuration template.

Description

As a user I want a template for the configuration. This increases the usability for me to start experimenting and the usage of the software.

Acceptance Criteria

• I can choose to open a template for the configuration file.
• The template opens when I click on it.

static predefined positions

User Story

As a user I want the possibility to have static predefined positions for my experiments that I can test network topologies from the same starting point.

Description

As a user I want the possibility to have static predefined positions, so that I start with the same starting conditions and properties for each experiment run.
I am able to set nodegroup movement as "static-predifend" with a list of all positions (Group view).
This helps me to test various experiments within network topology.

Acceptance criteria

• I can activate the field "Static-predefined" in the config file

External movement trace

User Story

As a user I need support for external movement traces so that I can test different movement traces within my experiments.

Description

As user I want to be able to activate the external movement traces so that I can test my experiments properly.
I need the support for external movement traces, so that I can follow up the traces where the nodes are moving in the experiment.
Furthermore, as user I can identify objects/nodes which have no movement trace.

Acceptance criteria

• I can insert the path of an external movement trace in the config file

traffic generation

User Story

As a user I want to configure traffic generation to test different criteria regarding my network topologies.

Description

As a user, I want to configure the traffic generation for my simulations. This will allow me to customize the traffic patterns and volume to meet specific needs and requirements.
In Coreemulab I am able to connect the periodic-file-generator to my TOML.
For The One I am able to configure traffic periodically (send traffic of nodegroups).

Acceptance criteria

• I can change the traffic configuration default value in the config file

output generation (core)

User Story

As a user I want to export my experiment configuration for CORE, so that I can run my experiment in that software.

Description

As a user i want to use CORE in my experiments. To include CORE in my experiments easily, I need the possibility to use CORE via configuration file only.

Acceptance criteria

• generate config file/call parameters for CORE
• output format is compatible with core

output generation (the-one)

User Story

As a user I want output files which are compatible with The ONE so that I can verify experiments with this software.

Description

As a user I want to have the opportunity to use the-one in my experiments for experimental reasons. To include the-one in my experiments easily, I need the possibility to use the-one via configuration file only.
I want to receive output files with results that are compatible with the-one.

This helps me as a user to experiment various network topology experiments and to compare the results from experiments with The ONE.

Acceptance criteria

• generate config file/call parameters for the-one
• output format is compatible with the-one
• output data from output files shall remain the same, if the same input was inserted in the config file

Set up testing pipeline

Networks

User Story

As a user I want to configure different networks, so that I can simulate network configurations

Description

As a user I want to be able to change my parameters within my network configuration, if needed.
For each network which is in need of parameters I can insert for simulations the value I want to test.

Acceptance criteria

• I can configure different/multiple networks
• I can insert values for each parameter within my network
• I am able to change the values of the network parameters

node groups (prefixes)

User Story

As a user I want different node prefixes so that I can test different experiments.

Description

Depending on the experiment, I am able to change the node prefixes in the configuration file.
For each experiment, the nodes stay exact the same, but I am able to change every node prefix for another experiment.

Acceptance criteria

• For each element of the node group the exact same prefix is displayed

Testing

User Story

As a developer I want a mature testing process, so that I can verify the correct functionality of my code.

Description

As a developer I have several tests for my code to verify the functionality and the relations within in the programmed parts.

Acceptance criteria

• Automated testing pipeline
• Pre-commit hooks for automated local tests

Tasks

• #24
• #26
• #60
• #69

support external core-automator patterns

User Story

As a user I need the support for external core-automator patterns to test a variety of experiments.

Description

As user I am able to connect external core-automator patterns.
There is the possibility for me to activate those in the configuration file.
Those settings in the config file, are possible to reuse for several runs and different experiments.

Acceptance criteria

• Results from external core-auomator patterns in simulation are the same as when manually inserted in the configuration file.

World size

User Story

As a user I want to set the world size in the input file so that I can test different world sizes within my experiments.

Description

As a user I want to set the world size, so that I can perform experiments in different dimensions.

Acceptance criteria

• The world size is changable in the configuration file
• I can insert values greater zero

Output folder structure

• pro Experiment pro Run pro RandomSeed
• comand line parameters zum Überschreiben/keepen

node groups

User Story

As a user I want configurable node groups so that I can test different devices and groups within a network.

Description

As a user I want node groups, so that i do not have to configure different node types individually, but can do this together in groups. This provides abstraction and clarity.
This ensures a proper testing process within my experiments.

Acceptance criteria

• Amount of node groups from config file equals the amount of node groups in the output file

Coverage Improvements

We want to achieve 80% Coverage overall

Use external template files for output generation

User Story

As a user I want to use my own templates for the output generation, so that I can make specialized changes for my experiment.

Description

As a user I want to use external templates files.
I am able to process them in the experimental process.
This increases the flexibility to use and reuse files that were prepared in advance for my configurations.

Acceptance Criteria

• I am able to use external files as templates instead of the default ones
• When I test, the output is the same as if I created the configuration file manually

node groups (network)

User Story

As a user I want different network interfaces depending on the node group to test different networks in my experiments.

Description

As a user, I want the ability to specify different network interfaces for different node groups in my simulations.
It will help me to test different different network configurations and scenarios for different groups of nodes in my experiments.

Acceptance criteria

• As user I have the possibility to choose on more than one interface for each node group in the config file
• I can select different interfaces for one node group in my config file before a run

Installation process

Docker? Go package? Binary?

parameterization for multiple runs from one config

User Story

As a user I want parameterization for multiple runs so that I am able to test different simulations with a single file.

Description

As a user, I want the ability to parameterize my simulations for multiple runs with a single configuration file.
The parameters of the configuration file shall remain the same before and after a run.

Acceptance criteria

• Results of parameters match input variables from configuration file specified by the user
• All not parametrized remain the same in all runs