RESOURCE MANAGEMENT LAYER Sample Clauses
RESOURCE MANAGEMENT LAYER. The Resource Management Layer contains the Infrastructure Manager of the testbed, which is used for controlling the computational capabilities located in the Physical Infrastructure Layer of the Testbed. The goal of this component is to provide an abstraction layer between the different clusters that can be part of the Testbed, effectively creating a unified entry point that can be exposed to the layer above. The preferred option within the 6G-SANDBOX umbrella is OpenNebula2, however, Testbeds are free to choose a different Infrastructure Manager as long as compatible Infrastructure-as-Code providers exist for their selection. In the case of 6G-SANDBOX, Terraform3, an open-source Infrastructure-as- Code management tool, acts as the interface between the Resource Management Layer and the Experimentation Lifecycle Layer, which is located above.
RESOURCE MANAGEMENT LAYER. The Resource Management layer is responsible for managing computational and network resources of the facility and will be a single reference coordination layer for the physical infrastructure as part of the four experimentation sites. The main components of this layer are: i) the Digital Twin enabler for interaction with the Experimentation lifecycle layer, ii) the Trial Network lifecycle manager, and iii) 6G-enablers for AI. The functional requirements concerning the components of the Resource Management layer are provided in Table 7 below. Table 7. Resource Management Layer Functional Requirements Priority Mandatory Description The Resource Management layer shall expose APIs for discoverability and secure access through the Common API framework (CAPIF), to its different functionalities Priority Mandatory Description Integration with digital twin platforms namely QualNet and EXata shall be considered for network modelling and simulation Priority Mandatory Description The Resource Management layer shall support the definition of a Trial Network Descriptor, including commands for the execution of actions such as the creation, modification, suspension, closure, and twinning of instances of the Trial Networks Priority Mandatory Description The Trial Network lifecycle manager shall handle the translation of the contents of a Trial Network Descriptor to the actions and configuration values necessary for the instantiation, modification of the Trial Networks Priority Mandatory Description The Trial Network lifecycle manager shall handle the management of the lifecycle of the Trial Network, from creation until decommission and the upkeep of their status, as well as the distribution of resources between the different Trial Networks Priority Mandatory Description The Resource Management layer shall support Infrastructure-as-code, including the creation of any required modifications, or the development of additional components that interface with IaaS provider to deliver additional functionalities Priority Mandatory Description The Resource Management layer shall be able to support other infrastructure managers as well. The infrastructure managers will allow to maintenance of an up-to-date report of the usage of the resources Priority Mandatory Description The Resource Management layer shall expose a list of possible RAN configurations to be utilized by the experimenters Priority Mandatory Description The Resource Management layer shall support connectivity configura...
RESOURCE MANAGEMENT LAYER. On top of the Physical Infrastructure layer, each Testbed Domain makes use of Infrastructure Managers (such as OpenNebula, OpenStack, PROXMOX, etc.) that allow the management of the heterogeneous capabilities in the testbeds from a single point of entry. • The Experimentation Lifecycle Layer acts as an interface between Experimenters (the users of a Trial Network) and the underlying Resource Management layer. Its main task is to manage the lifecycle of the different Trial Networks, which encapsulate the resources from the testbed that are made available to the experimenter. Access to the functionality is provided to Trial Network users mainly in the form of standardized RESTful APIs. These APIs may be complemented with one or more Web Portals that ease the usage of parts of the API, but which are not mandatory and do not replace the APIs. This architecture gives support to an undetermined number of Trial Networks, which can co-exist inside the testbed, sharing the available underlying resources but isolated from each other so that no experimenters can have access to data or computational resources that have not been reserved for their use case. An alternative view of the 6G-SANDBOX reference architecture is illustrated in Figure 5 below. This figure provides a more simplified perspective on the 6G-SANDBOX reference architecture, which is more in line with the architectural diagrams found in various standardization bodies. Figure 5. Alternative View of 6G-SANDBOX Architecture The following sub-sections provide additional details for each of the layers and the Trial Networks.