EXPERIMENTATION LIFECYCLE LAYER. The 6G-SANDBOX Experimentation Lifecycle layer encompasses a powerful software suite which will include i) a standardized API framework and ii) a powerful experimentation toolbox to support the experimentations. All of the results (experimentation methodology, KPI/KVI definitions, and values from the measurement campaigns) will be hosted in an open repository, namely the KPIs/KVIs repository. Based on the information provided above, Table 8 below outlines the requirements specific to the experimentation layer. Table 8. Experimentation Layer Functional Requirements REQ-EXP-FUNC- 1 Exposure of APIs towards the experimenter Priority Mandatory Description The Experimentation layer shall expose open APIs enabling the Vertical experimenter to access the Facility, define and conduct experiments as well as retrieve the results REQ-EXP-FUNC- 2 Support of specific plugins for modularity Priority Mandatory Description The manager of the Experimentation layer shall support the development, execution, and analysis of test plans by utilizing an architecture with plugins for any additional extensions
EXPERIMENTATION LIFECYCLE LAYER. The Experimentation Lifecycle Layer provides the following functionality: • Acts as interface between the Experimenter and the underlying Testbed, allowing the definition, creation, management, and removal of Trial Networks that the Experimenters can use. • Controls the lifecycle of the Trial Networks, keeping track of status and resource usage for each individual Trial Network. It is expected that this layer will be able to act autonomously, for example, suspending unused Trial Networks if resources need to be freed, or stopping them if malicious behavior is detected. • Provides a collection of Trial Network templates, which can be used by Experimenters for deploying pre-defined Trial Networks for common usages or used as a base for defining new Trial Networks better tailored for their needs. 2 xxxxx://xxxxxxxxxx.xx/ 3 xxxxx://xxx.xxxxxxxxx.xx/ • Housing the 6G Library, which is a collection of components that can be deployed as part of a Trial Network. These components can be physical devices that are made available to Experimenters (in this case, most likely being assigned to a single Trial Network at a time), or software components that can be instantiated on multiple Trial Networks independently and concurrently. The necessary logic for the management of the Trial Network’s lifecycle is implemented in the Trial Network Life Cycle Manager (TNLCM). It is envisioned that this component performs the following functions: • Translating the contents of the Trial Network Descriptors into directives for the layers below. These directives will be handled either by the Infrastructure –as Code manager (which will be ultimately executed by the Infrastructure Manager) or by the Automation Framework. The Automation Framework is composed by the set of tools that allow the management and configuration of heterogeneous hardware and software components, and that may require additional interactions that cannot be performed directly by the Infrastructure Manager. • Giving information to Experimenters on how to gain access to the components deployed inside their Trial Networks. • Controlling the status of each Trial Network, as well as tracking the usage of resources using information provided by the layers below. This information is to be exposed though an API to trusted entities, for example, the AI Module. • Allowing trusted entities (Experimenters of the AI Module) to control and modify the state of the Trial Networks that they have access to.
