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 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:
- Listing the Base Stations and/or sectors (see GSMA NG.116 v3.0, Section 3.4.2)
- Listing the regions based on geographical partitioning (see GSMA NG.116 v3.0, Section 3.4.2)
- Specifying a country or a state or a region
- Selecting the boundaries on a google map, which is then converted into for example, a rectangular shape with lat-long boundaries
- Etc.
Further, OOF has to anyhow generate Slice Profiles which shall contain CoverageAreaTAList.
Note: At present, coverageArea is specified as a string (specifying a region or a city). We propose it to be specified as a list of zone numbers from UUI, where a geographical region is split into zones on a grid. For example, in below figure, a slice is requested in (9,10,15,16).
Ref.: GSMA NG.116 v3.0, Section 3.4.2
Solution Proposal: Based on above, a DB would need to be pre-populated that specifies the mapping between zone numbers and TA(s) serving that zone. This DB can be CPS (currently Config DB). OOF shall access this DB to fetch the TA(s) for each zone requested by the slice consumer. After accessing the DB to fetch the TA(s), OOF has to remove duplicate TA entries when forming the CoverageAreaTAList. For example, Zone 15 may be served by TA_1 and TA_3, while Zone 16 may be served by TA_3, TA_6 and TA_7. So when constructing CoverageAreaTAList, TA_3 entry should not be duplicated.
During RAN/Core NSSI selection, OOF can check if the coverageAreaTAList is a subset of the coverageAreaTAList of an existing RAN/Core NSSI (when sharing is allowed) when determining feasibility of reuse.
For NSI selection, for the above proposal of coverageArea specification, OOF can check if the coverageArea is a subset of the coverageArea of an existing NSI (when sharing is allowed) when determining feasibility of reuse. It would be better to do this check in a separate method, so that it can be easily replaced by another one, when a different approach of specifying coverageArea is adopted. This check can be taken up even beyond H-release.
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.
| Slice Profile Attribute that needs decomposition | Decomposed Value sent to Near-RT RIC | RRM policy value to be sent to CU/DU | Remarks |
|---|---|---|---|
| maxNumberofUEs | Based on RRC (RRM Policy) distribution across cells (NRCellCUs), maxNumberofUEs split to be determined (using activityFactor). | Total RRC (across NRCellCUs, GNBCUCPFunctions for the S-NSSAI) to be determined based on activityFactor and maxNumberofUEs. Then RRC to be distributed across the NRCellCUs in the coverageAreaTAList based on current RRC occupancy levels (i.e., % already consumed by other slice instances). |
|
| Total DRBs (across GNBCUUPFunctions) to be determined to be determined based on activityFactor and maxNumberofUEs (and average number of radio bearers per UE???). Then DRB to be distributed across the GNBCUUPFunctions in the coverageAreaTAList based on current DRB occupancy levels (i.e., % already consumed by other slice instances). |
| ||
| areaTrafficCapDL, areaTrafficCapUL | Based on expDataRateDL (currently copied from dLThptPerSlice) and expDataRateUL (currently copied from uLThptPerSlice) and the ratio of coverage area of the Near-RT RIC over the total coverage area (determined by number of cells mapped under it). | ||
| expDataRateDL, expDataRateUL | (At present, this has to be determined from the value in the Slice Profile divided by (number of UEs * activity factor. Later when this carries the data rate per UE correctly, no decomposition is required)) |
|
|
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).
- End points should also be considered for NSSI selection.
- Potential enhancements for TN NSSI selection to be discussed further.
4. Enhancements in Slice Profile generation
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 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 a mechanism to select the most appropriate one. This would require 'normalization' of attributes, and whether greater closeness for one or more attributes should be preferred over a normalized sum of closeness across all attributes.
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.
| Scenario | Action(s) | Scope in Honolulu |
|---|---|---|
| Core NSSMF has decided to instantiate a new Core NSSI. All Core NFs have to be instantiated newly | OOF will be triggered for determining the Core NF placement | In scope, see details below the table |
| Core NSSMF has decided to instantiate a new Core NSSI. Some Core NFs have to be instantiated newly (e.g., UPF), while others shall be reused (e.g., AMF) - this is determined by examining the shareability of Core NFs and feasibility to support the new NSSI (based on capacity/resource occupancy levels/scaleability). | OOF will be triggered for determining the Core NF placement for the new Core NFs. In case of scaling any existing Core NF, OOF shall be triggered for placement of new instance. (Note: This also has implications in Modeling of Core NS, and resourceSharingLevel of Core NSSI) | Out of scope |
| Core NSSMF has decided to reuse an existing Core NSSI. All Core NFs shall be reused, without scaling. | No impact. | Covered |
| Core NSSMF has decided to reuse an existing Core NSSI. All Core NFs shall be reused, one or more with scaling. | OOF shall be triggered for placement of new instance. | Out of scope |
| Core NSSMF has decided to reuse an existing Core NSSI with modifications. Some Core NFs shall be reused (with/without scaling) while others have to be instantiated newly or selected from those serving other NSSIs. | OOF will be triggered for determining the Core NF placement for the new Core NFs. In case of scaling any existing Core NF, OOF shall be triggered for placement of new instance. For selecting Core NFs serving other NSSIs, OOF may be triggered considering placement also. (Note: This also has implications in Modeling of Core NS, and resourceSharingLevel of Core NSSI) | Out of scope |
Considerations for Honolulu
| Attribute | Details |
|---|---|
| Remaining Capacity (feasibility check) | Capacity could be simply based on number of NF instances that can be supported in a DC (configured), and number of instances active currently (fetched from AAI). Question: Will this work in case of CNFs? |
| Distance from RAN | Where will distance or DC location be specified? Will it be part of AAI or ??? Shall we ignore this because of next attribute? |
| Latency of transport | Part of TN BH Slice Profile |
Question: Which Core NFs shall we consider for placement - only UPF to start with?
6. Enhancements in NST selection
Refer NST Selection for relevant info.
7. Slice Modification recommendations