...
- 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. How/where this decision shall be taken shall be left to the implementation (API Handler or ...).
- RAN NSSI workflow should invoke RAN NF NSSI workflow for RAN NF NSSI related actions for Option 1 (due to workflow separation). This shall be in the same format as NSMF would invoke RAN NSSMF for Option 2 (for RAN NF NSSI related actions).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. How/where this decision shall be taken shall be left to the implementation (API Handler or ..., for example with endpoints and Slice Profile info, etc. for allocateNSSI API (for allocating RAN NF NSSI - see below for RAN NF NSSI workflow actions).
- RAN NF NSSI workflow should be concerned only about RAN NF NSSI actions, including:
- (Both options) RAN NF NSSI selection (may not exist today for Option 1) upon allocateNSSI call for RAN NF NSSI. (Note)
- RAN NF NSSI modification (Option 1: During NSI/RAN NSSI reuse scenarios during slice allocation, as well as when NSI/RAN NSSI is decided not to be terminated; Option 2: During NSI reuse scenario as well as when NSI is decided not to be terminated)
- (Both options) RAN NF NSSI termination determination by calling OOF (this may not exist today for Option 1, and RAN NF may be automatically terminated when a RAN NSSI is decided to be terminated), and associated actions upon deallocateNSSI call for RAN NF NSSI.
- (Both options) RAN NF NSSI activation and deactivation.
Note: This may require some modeling updates in the manner in which RAN NSSI and RAN NF NSSI are associated (templates and in AAI).
- (Option 1) RAN NSSI workflow of RAN NSSMF shall invoke TN NSSMF in a model-driven manner, i.e., based on the RAN NSSI constituents or the Slice Profiles returned by OOF for selectNSSI API call for RAN NSSI selection. This will enable extensibility and customization (e.g., no Fronthaul slicing in the short term).
- (Option 1) RAN NSSI workflow shall first invoke RAN NF NSSI workflow followed by TN NSSMF API calls. This applies in general for all the lifecycle actions (allocate, activate, deactivate, deallocate, modify).
- To be checked
- Which workflow shall be invoked for Closed Loop actions involving the RAN, and how it shall be determined?
- If RAN NSSI workflow calls RAN NF NSSI workflow via API handler, should job status, etc. be introduced, similar to the interface between NSMF and NSSMFs?
AAI
No changes foreseen. Schema shall support both 3 as well as 5 NSSIs linked to an NSI, and 3 or 5 Slice Profiles linked to a Service Profile.