Experimenter Tools

For the experimenters we foresee the following tools and services:

A. 5GinFIRe Portal

The 5GinFIRE portal will be the public access point for uploading or viewing available VxFs of the platform and experiments in terms of Network Service Descriptors. Users will Sign Up and upload their descriptors. The user will also make a request for an experiment resources/testbed, tentative schedule, etc. The 5GinFIRE wiki will have guidelines of how to use the portal.

B. OSM Launchpad

OSM Launchpad is a place that can be used in some cases to design in detail an NSD directly on OSM. This can be used in complex deployments

C. Access to Virtual Machines and other services

It is expected during the experiment to have direct access to deployed virtual machines and services

5GinFIRE offered services and tools target to accommodate the following envisaged user roles. All users are assumed to be authenticated via the portal:

• Experimenter: This role represents the user that will utilize our services and tools to deploy an experiment. That is the experiment description in terms of e.g.: NSD (Network Service Descriptor) or TOSCA Specification
• VxF developer: This role is responsible to upload VNF and NSD Descriptors in the 5GinFIRE services
• Testbed provider: This role represents users that are responsible for testbed administration, configuration, integration, adaptation, support, etc

A.  Terminology

Experiment: In 5GinFIRE it is defined as a set of experimentation activities that will be conducted during an allocated time-slot (probably spanning for several days); the experiment may probably involve multiple 5GinFIRE test-beds; it might require the utilization of several network services, which will be indicated during the experiment definition and will be validated by the 5GinFIRE operations; these network services may be used by the experimenter during the allocated timeslot. it is a set of experimentation activities that will be conducted during an allocated time-slot (probably spanning for several days); the experiment may probably involve multiple 5GinFIRE test-beds; it might require the utilization of several network services, which will be indicated during the experiment definition and will be validated by the 5GinFIRE operations; these network services may be used by the experimenter during the allocated timeslot.

VxF: complex constellations of virtual functions, all running on a mix of real and virtual network or computing elements. We refer to virtual functions as VxFs when we do not want to distinguish between network-centric functions and vertical-centric functions.

B. 5GinFIRE Experimentation Workflow

Experimenter

The figure displays an overview of the experimentation workflow process. There are three main horizontal lines: the experimenter, the 5GinFIRE operations and the 5GinFIRE testbed providers that interact during an experimentation life-cycle. At the simplest case, users signed-up to the platform via the portal will be approved by 5GinFIRE Operations. To perform an experiment on top of the 5GinFIRE infrastructure at its simplest form the user needs to create an experiment in Network Service Descriptor format, , etc and select available VNFs or deploy new ones through the portal. Then he needs to compose the experimentation solution. This can be done either as an OSM Network Service Descriptor (NSD) or in terms of a TOSCA specification. In a first version of the architecture, the user will provide an OSM-supported YAML description of the network service, potentially aided by a graphical composer of OSM Launchpad.  As soon as everything is in place for an experiment description, the experimenter selects the testbed facility based on resource availability after the experiment is submitted for validation.

5GinFIRE prepares a process for validating an experiment in terms of various rules such as schedule, resource availability, etc. The validation process is closely performed together with the target testbed providers. We expect this to be iterative in various cycles involving the experimenter by either asking questions or modifying any experiment details and parameters.

As soon as an experiment is approved, it is scheduled by 5GinFIRE operations for deployment. Through the portal or OSM the 5GinFIRE operations will create a deployment (i.e. uploading descriptors etc) and OSM will later on orchestrate it (trigger the services instantiation). There will be a close collaboration during the management of the orchestration/deployment with the testbed providers. After deployment the resources are available and accessible to the experimenter.

In the end of the experiment schedule, the resources of the experiment are released and access is revoked. We expect though that any available results of the experiment will be available to the experimenter.