...
Beyond Honolulu, we can further enhance it to generate the optimal decomposition using more sophisticated mechanism, and additional inputs.
maxNumberofUEs |
coverageAreaTAList |
latency |
uEMobilityLevel |
resourceSharingLevel |
| Slice Profile Attribute that needs decomposition | Decomposed Value sent to Near-RT RIC | RRM policy value to be sent to CU/DU/RU |
|---|---|---|
| maxNumberofUEs | RRC (NRCellCU, GNBCUCPFunction) = | |
| expDataRateDL (Integer), expDataRateUL (Integer), areaTrafficCapDL (Integer), areaTrafficCapUL (Integer), overallUserDensity (Integer), | ||
| cSAvailabilityTarget (Float), cSReliabilityMeanTime (String), , expDataRate (Integer), msgSizeByte (String), transferIntervalTarget (String), survivalTime (String | ||
The resource type of interest for an RRM Policy.
allowedValues: PRB (for NRCellDU, GNBDUFunction) RRC connected users (for NRCellCU, GNBCUCPFunction) DRB (for GNBCUUPFunction) See NOTE 2and NOTE 4 |
3. Enhancements in NSI/NSSI selection
...
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?
...