Note: This is a stretch goal for I-release.
1. General Remarks
- SO (TN NSSMF) does not support call to OOF for NSSI selection. This means, when a new NSI is created, TN NSSI (FH, BH and MH) have to be created newly.
- SO (TN NSSMF) does not support call to OOF for determining if an NSSI shall be terminated or not. So based on the API (deallocate or modify) SO (TN NSSMF) shall decide to terminate the TN NSSI (FH, BH or MH) or not.
2. High-level requirements
- ONAP NSMF shall support Option 1 and Option 2 in a model-driven manner.
- ONAP RAN NSSMF shall support Option 1 and Option 2 in a model-driven manner.
- In case of Option 2, NSMF shall communicate with TN NSSMF for FH and MH NSSI LCM calls. This shall be aligned with the calls done by RAN NSSMF to TN NSSMF for Option 1, to keep it uniform.
- For FH and MH, we take some assumptions for the short-term: for e.g., pre-provisioned endpoint info for RU, CU and DU. If feasible, endpoints should be a list, to enable multipoint to multipoint connectivity in future. Open point: how should we specify which RU(s) should be connected to which DU(s)?
3. High-level Impacts
SDC
No code impacts expected. Templates have to be defined for NST containing 5 NSSTs (RAN NF, Core, TN FH, TN MH and TN BH). Suitable Service and Slice Profile templates should be available.
OOF
OOF should ensure that the Service Profile decomposition is done into Slice Profiles, wherein the Slice Profiles to be created are determined from the NSSTs within the NST.
SO (NSMF)
Important Note: Almost all actions below can be implemented in a model-driven manner. For example, SO (NSMF) can invoke appropriate calls to the NSSMFs for each of the (first-level) NSSI associated to the NSI or for each Slice Profile received from OOF. This will enable future extension and customization based on deployment needs without any code impacts (e.g., Fronthaul may not be "sliced" in some deployments).
New NSI creation
- SO (NSMF) shall invoke SO (TN NSSMF) with allocateNSSI calls 3 times, for BH, FH and MH NSSIs. The relevant endpoints info and Slice Profile info shall be passed to TN NSSMF.
- SO (NSMF) shall update AAI with relationship between FH/MH NSSI and NSI.
NSI reuse
- SO (NSMF) shall invoke SO (TN NSSMF) with modifyNSSI calls 3 times, for BH, FH and MH NSSIs. The relevant endpoints info and Slice Profile info shall be passed to TN NSSMF.
NSI activation/deactivation
- SO (NSMF) shall invoke SO (TN NSSMF) with activateNSSI/deactivateNSSI calls 3 times, for BH, FH and MH NSSIs.
NSI deallocation
- When OOF returns to SO (NSMF) that the NSI should be terminated, SO (NSMF) shall invoke SO (TN NSSMF) with deallocateNSSI calls 3 times, for BH, FH and MH NSSIs.
- When OOF returns to SO (NSMF) that the NSI should not be terminated, SO (NSMF) shall invoke SO (TN NSSMF) with modifyNSSI calls 3 times, for BH, FH and MH NSSIs.
- SO (NSMF) shall update AAI with relationship between FH/MH NSSI and NSI.
SO (RAN NSSMF)
- Clear workflow separation to be ensured between top-level RAN NSSI (as in Option 1), and RAN NF NSSI (for both options).
- Upon receiving a call from NSMF, SO (RAN NSSMF) should determine if the top-level RAN NSSI workflow or RAN NF NSSI workflow should be invoked.
- RAN NSSI workflow should invoke RAN NF NSSI workflow.
- RAN NF NSSI workflow should be concerned only about RAN NF NSSI actions, including:
- RAN NF NSSI selection (may not exist today for Option 1) upon allocateNSSI call for RAN NF NSSI.
- RAN NF NSSI termination determination (may not exist today for Option 1), and associated actions upon deallocateNSSI call for RAN NF NSSI.
- RAN NF