Potential requirements impacting OOF in Honolulu release are described below.
1.
...
coverageArea to
...
coverageAreaTAList mapping
User provided input is coverageArea. Service Profile contains coverageArea whereas Slice Profile contains coverageAreaTAList (Ref.: 3GPP TS 28.541). In Guilin, the user provided coverageArea is passed unchanged down to NSSMF, and this is then used to fetch the list of cells from Config DB.
Requirement for Honolulu
It would be better to do coverageArea to do this coverageAreaTAList mapping in OOF as part of NSI Selection procedure. Reason: SO (NSMF) shall pass Service Profile which contains only CoverageArea. OOF has to determine if an existing NSI can be reused or not which would also require to check for the NSI coverage. It would be better to do this based on CoverageAreaTAList, as it would enable flexibility to specify CoverageArea in different forms, for example:
...
2. Decomposition of RAN NF Slice Profile for each Near-RT RIC
The Slice Profile attributes should be decomposed further into a form that the Near-RT RIC can use further. This decomposition has to be done for each dimension-related attribute (e.g., maxNumberofUEs, areaTrafficCapDL/UL) in the Slice Profile.
For Honolulu, we can start with a very simple approach of doing this decomposition based on the number of cells controlled by each Near-RT RIC for a given S-NSSAI.
Alternatively, we can do the split based on the PM data collected for each S-NSSAI at cell level, and taking capacity into consideration. For example:
- Based on PDU sessions setup successfully overall in that cell (PM data) and consider the maximum number of UEs that can be supported by the cell (and what is already allocated) to determine maxNumberofUEs for each Near-RT RIC scope for that S-NSSAI.
| Cell | Near-RT RIC Id | PDU sessions setup successfully | Maximum number of connections that can be supported (unallocated) |
|---|---|---|---|
| A | 1 | 50 | 75 |
| B | 1 | 25 | 100 |
| C | 2 | 40 | 90 |
If Slice Profile has maxNumberofUEs = 120:
maxNumberofUEs for Near-RT RIC 1 = 120*(25+40)/(50+25+40) subject to constraint of supporting only a maximum of 90% of (75+100).
maxNumberofUEs for Near-RT RIC 2 = 120*(50)/(50+25+40) subject to constraint of supporting only a maximum of 90% of (90).
- Based on DL/UL PRBs used (PM data) and consider the areaTrafficCapDL/areaTrafficCapUL that can be supported by the cell/TA (and what is already allocated) to determine for each areaTrafficCapDL/areaTrafficCapUL for each Near-RT RIC scope for that S-NSSAI.
Beyond Honolulu, we can further enhance it to generate the optimal decomposition using more sophisticated mechanism, and additional inputs.
3. Enhancements in NSI/NSSI selection
Consider capacity/resource occupancy levels of existing NSI/NSSI. Details to be discussed. Potential inventory sources could be AAI and DCAE (Data Lake), depending on whether we look at provisioned capacity, or real-time occupancy levels (which might also enable analytics/prediction in future).
4. Enhancements in Slice Profile generation
...
- 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
In Honolulu, we can consider 2 cloud instances (one edge DC and one regional DC), and based on the Slice Profile, we could consider Core NF placement - e.g., for a URLLC slice (low latency), we could place UPF in the edge DC.
6. Enhancements in NST selection
...