...
When generating Slice Profiles for an existing NSI (NSI reuse scenario), currently OOF uses the sub-net capabilities and the Service Profile as inputs for generating the optimum set of Slice Profiles. However, when reusing an existing NSI, it might be be more appropriate to generate Slice Profiles that are "close" to existing Slice Profiles supported by the respective NSSIs from a performance requirement point of view (the feasibility part is covered by considering capacity/resource occupancy levels of existing NSSIs). This, in turn, would make the NSI more homogeneous/uniform in nature, which will have benefits during resource allocation, scaling and other orchestration (LCM) actions.
In general, we could split the Slice Profile attributes into 2 categories: performance-related (e.g., latency, throughput) and dimension-related (e.g., user density)
An example approach would be:
- Generate valid combinations of Slice Profiles based on sub-net capabilities, meeting the Service Profile constraints.
- Select the Slice Profiles which are 'closest' to existing Slice Profiles in terms of performance requirements - 'closeness' could be given a weight per attribute (we could start with a limited set of attributes, say latency, throughput, we could end up in 2 scenarios: say, 2 Slice Profiles (e.g., RAN and Core) are close, while 3rd (TN) is far off, all 3 are 'somewhat' close - in such a case, we should have some mechanism to select the
5. Core NF placement
6. Enhancements in NST selection
Refer NST Selection for relevant info.