Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

This page captures the consolidated list of key assumptions.

1. Common aspects

  1. Association between NST and NSST shall be fixed at design time. In other words, an NST shall be composed of a set of NSSTs at design time.
  2. As a result of (1), the AllocateNSSI API shall contain NSST info. This shall be re-visited beyond Guilin.
  3. If the NSSMF is not capable of NSSI selection, ONAP acting as NSMF shall perform NSSI selection also and then pass the NSSI info in the AllocateNSSI API. This situation shall arise only when connecting to an external NSSMF, as all NSSMFs within ONAP shall support NSSI selection.

2. Common NSSMF

  1. The API from NSMF towards NSSMF shall be based on 3GPP APIs with the following exceptions:
    1. NSST id shall be passed in the AllocateNSSI API if the NSSMF is capable of NSSI selection. This is due to assumption (1) in "Common Aspects" - see above.
    2. NSSI id shall be passed in the AllocateNSSI API if the NSSMF is not capable of NSSI selection. This is to enable interoperability with external NSSMFs that aren't capable of NSSI selection (so ONAP acting as NSMF shall also do NSSI selection).

3. Core Slicing

  1. No impact is foreseen for Closed Loop or Intelligent Slicing for updating the configuration of the core NSSI.

4. RAN Slicing

  1. RAN NFs are assumed to be instantiated apriori. So in case of RAN NSSI creation, the step involving RAN NF instantiation shall be skipped.

5. Transport Slicing


6. RAN & Transport Slicing interactions

Option 1 = RAN NSSI shall comprise of RAN NF NSSI, FH NSSI and MH NSSI. RAN NSSMF shall be responsible for RAN NSSI and RAN NF NSSI orchestration, and shall trigger Transport NSSMF for FH and MH NSSI orchestration. NSI shall comprise of RAN NSSI, TN (BH) NSSI and Core NSSI.

Option 2 = RAN NSSI shall denote just RAN NF NSSI. NSSMF shall be responsible for triggering TN NSSMF for FH, MH and BH NSSI orchestration. NSI shall comprise of RAN (NF) NSSI, FH NSSI, MH NSSI, BH NSSI and Core NSSI.

  1. Both options for RAN and Transport Slicing interaction shall be supported in Guilin release. RAN NSSMF within ONAP shall support Option 1, while external RAN NSSMF shall support Option 2. NSMF within ONAP shall support both options.
  2. In a single ONAP deployment, only one of the 2 options shall be supported, and shall be known apriori. As a consequence, the NSTs also shall reflect only the option that is supported in the deployment. For example, if Option 1 is supported, NST shall comprise of RAN, Core and TN (BH) NSSTs, while when Option 2 is supported, NST shall comprise of RAN, Core, TN (FH), TN (MH) and TN (BH) NSSTs.
  3. SO (NSMF) shall know which Option is supported by examining the NST (Option 1 => NST contains 3 NSSTs, Option 2 => NST contains 5 NSSTs). OOF shall operate based on the NST contents in a model-driven way.

7. KPI Monitoring

  1. No trigger for KPI monitoring shall be sent from SO or other micro-services in DCAE. The KPIs to be computed by PM Handler MS shall be configured via Policy, and the NSI/NSSI for which the KPIs shall be computed shall be determined by accessing AAI before the computation.
  2. It is assumed that the NFs already "know" which PM data should be reported to ONAP.

8. Closed Loop

  1. Any resource re-allocation for slice resource optimization shall be computed based on rules by SDN-R for the RAN (without involving OOF).

9. Intelligent Slicing

  1. The training shall happen outside ONAP, and the ML models shall be onboarded as an MS in DCAE. This MS shall not be part of ONAP repos, and shall be used only for PoCs/demos.


  • No labels