Exposed entity and access: 5G-VINNI Portal (WEB UI and REST API) https://patras5g.eu , VPN access to deployed NS

Description: Service Catalog exposure (TMForum), Service Ordering Support(TMForum), scheduled orchestration, and VPN access to deployed NS. Access to monitoring data of various points

Exposed entity and access: 5G-VINNI Portal (WEB UI and REST API) https://patras5g.eu NFVO onboarding. Will be available at the level of 5G-RAN, 5G-CORE and Transport Controllers

Description: Upload/manage 3rd party VNFs/NSDs to facility NFVO (via web UI and REST API). scheduled NSD orchestration, Depending on the capabilities and if the underlying technologies allow this

Exposed entity and access: Access to facility OSM (web and NBI SOL005)

Description: This will be available in special cases where the portal access is not enough. In most cases a separate tenant will be created ( OSM SIX )

Exposed entity and access: Access to facility NFVI

Description: Use of Openstack (Rocky) APIs and HORIZON UI. Tenant will not have administrative privileges. Allowed to install VMs on subnets accessible by the 5G core. In certain cases will be allowed to view VNFs deployed by the OSM tenant project

This phase begins when CSP receives a service order from the CSC. At that moment, a VINNI-SD is created out of VINNI-SB and stored in OSM repository. Then, CSP checks if that VINNI-SD is feasible (e.g. check if all the mandatory parameters have been specified, if there is enough capacity, etc.), and if so, sends corresponding network slice requirements to NOP. With these requirements, the NOP carries out a set of operations arranged into sub-phases: NST design and NST on-boarding.
For the first sub-phase, the NOP takes the received requirements and translates them into the following tuple: {required NST, instantiation parameters}, so NOP can deploy the NSI when and where required. For the preparation phase, only the first field of this tuple is relevant. The required NST shall follow the information model introduced at the beginning of Section 4 and shown in Annex A. This NST can already exist (pre-defined NST, designed beforehand) or not (NST created on demand) in the service catalogue. To handle these two scenarios, two operations are made available to NOP through NST management interface (Section 3):

• nst-create: allows designing an NST from scratch. This operation is triggered by the NOP when there is no pre-defined NST that can be reused for the definition of the required NST.
• nst-update: allows modifying some fields from a given NST. This operation is triggered when the required NST can be obtained by updating some of the content of an already existing NST.
  Either of the abovementioned options allows NOP to have the required NST designed, and thus the first sub-phase completed. From that moment onwards, the NST is on-boarding can get started.
  In this second sub-phase, the NOP aims at injecting the required NST into the service catalogue. This process not only consists in on-boarding the NST itself, but also the NFV-NS and VNF Packages referred by the NST (see information model in Annex A). OSM’s NBI offers APIs that support CRUD (Create, Read, Updated, Delete) operations to handle these NFV-NS and VNF packages (and their contained NSDs and VNFDs). In these operations, the necessity checks to validate in-model and cross-model consistency are performed. These API calls are implemented over the NFV-NS/VNF Package management interfaces and the NSD/VNFD management interfaces described in Section 3.
  Once the on-boarding process finishes, the NST is stored in the service catalogue, so it can be used for NSI creation later on. At this moment, the NOP can invoke two operations from NST management interface (section 3):
• nst-list: allows listing NSTs available in the service catalogue.
• nst-show: allows showing the content of a given NST.

When the NOP finishes invoke either of the two operations, the preparation phase gets finished.

Once the NST and corresponding NS/VNF Packages have successfully been on-boarded in the service catalogue, they can be used as deployment templates for the actual NSI deployment. Alike the preparation phase, the commissioning of the NSI from the NST is a phase that can be split into two sub-phases: network slice instantiation and NSI configuration.
Network slice instantiation consists of the day-0 operations that allows creating an NSI where all the components are instantiated. These operations are defined at all the abstraction levels, ranging from VDU level (e.g. VNF component) to network slice level, and are invoked using the VNF, NFV-NS and network slice lifecycle management interfaces described in Section 3. To trigger the instantiation of a network slice, the NOP will consume the nsi-create operation from the network slice lifecycle management interface.

For nsi-create operation, the two fields of the tuple {required NST, instantiation parameters} that was derived in the preparation phase is now needed. A brief overview of the steps that OSM takes when this operation is invoked is shown below:

1. First, the NOP analyses the content of the NST and decompose it into its constituents: network slice subnets and virtual links connecting them.
2. Secondly, for each network slice subnet, the corresponding NSSI is created. This NSSI is an NFV-NS instance. For the deployment of this NFV-NS instance, the following information is considered:
   a) Instantiation parameters: from the tuple {NST, instantiation parameters} derived in the preparation phase. The NOP extracts from these parameters the requirements that are relevant for the network slice subnet to be instantiated.
   b) NSD information element: from the IM of the required NST (see Annex A). This information element points to the NSD that will be used for deploying the NFV-NS instance. This instance can be deployed in various forms (e.g. with different topologies, with different capacity) and with different deployment constraints considering the above instantiation parameters, by using the mechanisms that NSD has for that end (e.g. flavoring, affinity/anti-affinity rules, etc).
   c) Iss-shared-nss information element: from the IM of the required NST (see Annex A). This information element specifies if the above NSD can be shared or not. If this information element set to YES, and if an already NFV-NS instance provides similar capabilities to those needed by the NSSI, then that NFV-NS instance can be associated with the NSSI. Otherwise, a new NFV-NS instance needs to be deployed.
3. Thirdly, for each virtual link providing inter-NSSI connectivity, the corresponding virtual link instance is created. For the deployment of this virtual link, the following information is considered:
   a) Instantiation parameters: from the tuple {NST, instantiation parameters} derived in the preparation phase. The NOP extracts from these parameters the requirements that are relevant for the virtual link to be instantiated.
   b) VLD information element: from the IM of the required NST (see Annex A). This information element points to the VLD that will be used for deploying the NFV-NS instance. This instance can be deployed in various forms (e.g. with different QoS parameters) considering the above instantiation parameters, by using the mechanisms that VLD has for that end (e.g. flavoring).

With the abovementioned steps, the NSI is already created, although not configured.
To start the configuration process, day-1 operations are required at the NSI components. Typical day-1 operations include model-driven interaction with (Virtual/Physical/Hybrid)NFs through the use of Juju charms, which allow NEPs to encapsulate their configuration mechanisms (e.g. YANG/NETCONF, Ansible, SSH+scripts). For (V/P/H)NF application layer configuration, two different kinds of Juju charms can be used: native charms and proxy charms. A brief comparison of these two Juju charms:.

Native charm vs proxy charm
Native: Juju charm used for those NFs that are able to run charms inside, e.g. cloud-like VNFs. NF interaction happens directly from the orchestrator
Proxy: Juju charm used for those NFs that do not support running charms inside, e.g. PNFs. Proxy charm uses the appropriate configuration protocol to interact with the NF and run the desired actions from the primitive

Once the NSI has been successfully commissioned, the NSI becomes a relevant object for further operation actions. Unlike 3GPP view, operation phase in OSM includes deactivation/activation (e.g. pausing/resuming) as part of the set of modification operations that can be triggered at run-time, depending on the outcomes resulting from the supervision and reporting activities carried out over the NSI throughout its lifetime.
Examples of basic supervising and reporting activities that the NOP can conduct over the NSI are allowed through the following operations, all exposed in the network slice lifecycle management interface:

• nsi-list: list of all operative NSIs
• nsi-op-list: show the history of operations that has been triggered over the NSI since its creation.
• nsi-op-list: shows the information of the operation over a NSI
• nsi-show: shows the record of the NSI
  Other more sophisticated activities can be performed, assisted by the MON module, or by the Bugzilla
  Depending on the information received from these supervision and reporting activities, the running NSI might need to be modified, in order to keep it in the desired state. For this end, the NOP can trigger a wide variety of day-2 operations over that NSI. These API-driven operations are quite aligned with the specificities indicated by the CSC in the VINNI-SD, and can fall into one of these categories:
• Operations at the virtualized resource level: includes operations that has a direct impact on the virtualized resources supporting the NSI. Examples of these operations include scaling operations (e.g. subjected to upper and lower thresholds), creation and deletion of performance measurement jobs, subscribe and notify operations for performance metrics and fault alarms, instantiation and termination of testing components to complete test campaigns, etc. Depending on the service exposure level selected by CSC , these operations can be performed at different abstraction levels, e.g. ranging from NSI level to VNF instance levels.
• Operations at the application level: includes operations that are relevant only for the specific functionality that the NSI offers. Examples of these operations include the addition, modification and deletion of new subscribers, changes in security parameters, changes in routing across the service chain, etc. Those actions need to be enumerated and codified in the constituent NFV-NS Packages the NST refers to and are exposed by the API as primary actions available in that given NSI.

As any other (on-demand) instance of a manageable entity, it is possible to decommission an NSI. This decommissioning means removing all the dedicated components and releasing their underlying resources, but not the shared and dependent components. For those components, they need to be re-configured and their resources should be adjusted accordingly. To illustrate this scenario, consider the case where a NSSI from the NSI that needs to be decommissioned was deployed using a running NFV-NS instance (e.g. a NFV-NS instance also serving other NSSI from another NSI). In such a case, where the NSSI from the NSI to be decommissioned is removed, the NFV-NS instance cannot be removed. Otherwise, the other running NSSI will be affected. To avoid this, when removing the required NSSI, the NFV-NS instance will be re-configured (e.g. disassociated from the removed NSSI) and scale-in accordingly.
As seen again, the lifecycle management of NSSI and NFV-instances, although dependent, are separate.
For the decommissioning phase, Spanish and Greek NOPs may invoke the nsi-delete operation through the network slice LCM interface.