Work Items
1. Frankfurt Improvements
No. | Track | Description | Jira | Priority | Impacts | Remarks |
---|---|---|---|---|---|---|
1.1 | NST selection | Implementation of NST selection in HAS | 1 | HAS | Common understanding of how to fetch template details from SDC | |
1.2 | Implement callback for NST selection | 1 | OSDF, SO | |||
1.3 | NSI selection | API improvements - For NSI selection, NSST details should be provided in the request from SO (NSMF). NumSolutions should be provided by SO. Service/Slice Profile attributes, json blob at the end | 1 | Domain type (AN/TN/CN) should be also included in the Slice Profile (Modeling consideration?) | ||
1.4 | OOF response shall NOT contain NSSI info (only NSI if available/usable, and Slice Profiles will be sent back). | 1 | ||||
1.5 | During NSI selection, when the attribute (e.g., reliability) in Threshold Policy is not part of Slice Profile, it should be ignored by HAS (error should not be returned) | HAS | Already implemented | |||
1.6 | Aggregate policy to be implemented, e.g., latency of all Slice Profiles (across subnets) chosen to be < latency in Service Profile. | 1 | independent improvement | |||
1.7 | When considering existing NSSI as a candidate, consider ALL slice profiles (not just “best” one). | 2 | ||||
1.8 | Slice profile generation - candidates should be generated at appropriate granularity | 1 |
| |||
1.9 | Slice profile selection - choose best one, based on service profile, subnet capabilities (and optionally existing NSSIs, if sharing is allowed???) | 1 | Priority can be revisited | |||
1.10 | Implement callback for NSI selection | 1 | OSDF | Additional components - SO | ||
1.11 | Selecting "final" solution(s) by OOF based on policy - minimum change policy, maximum slice count policy, reuse policy, etc. subject to the numSolutions limit sent by SO. | 2 | HAS | OOF API shall still contain 'list' of solutions OSDF - translation of Policy | ||
1.12 | NSI Termination | API and response for NSI termination - yes or no (check Policy also) | 1 - functionality 2- OOF impacted | OSDF, SO | Request should come from SO acting as NSMF |
2. NSSI Selection
No. | Track | Description | Jira | Priority | Impacts | Remarks |
---|---|---|---|---|---|---|
2.1 | NSSI Selection | Select appropriate NSSI, return "no solution" if no solution exists (Send Slice Profiles also in case of RAN NSSI selection for Option 1) | 1 | Intention is to make NSSI selection domain agnostic. | ||
2.2 | Implement callback for NSSI selection | 1 | ||||
2.3 | NSSI Termination | API and response for NSSI termination - yes or no (check Policy also) | 1 - functionality 2 - OOF impacted | OSDF, SO | Request should come from SO acting as NSSMF |
2 Comments
Danh D. Le
Hi Swaminathan Seetharaman
On the point 1.3- Domain type (AN/TN/CN) should be also included in the Slice Profile (Modeling consideration?).
In case a single NSSMF provides functionalities for different domain (AN/CN), then how does it distinguish which domain NSSI is being asked?
Do you have further information about the modeling aspect of this point?
Thanks,
Danh
Swaminathan Seetharaman
Hi Danh D. Le
Yes, domain type should also be included. Details of modeling aspects can be found at Modeling enhancements.
Thank you.
Swami.