This page captures the consolidated list of key assumptions.
1. Common aspects
- 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. Common NSSMF
3. Core Slicing
4. RAN Slicing
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.
- 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.
- 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.
7. KPI Monitoring
- 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.
- It is assumed that the NFs already "know" which PM data should be reported to ONAP.