/
E2E Network Slicing use case - Enhancements

E2E Network Slicing use case - Enhancements

Owned by Ahila P
Mar 22, 2022
5 min read

Below are the potential area of enhancements and new features discussed by the Network Slicing use case team and it can be implemented in future releases.

E2E Slicing solution

  • Enhancements to Service and Slice Profiles in 3GPP TS 28.541 Rel. 16, and CST based on latest NGMN NG.116. Associated modeling enhancements.

  • Optional input by operator to enter SST/slice type (see mail on S-NSSAI topic) – if this is allowed, then accordingly obtain the relevant mandatory and optional inputs from the user for creating the slice.

  • Stitching of e2e slice – for this, perhaps a better solution for endpoints (related to item (4) in your list) - how it will be ‘discovered’ by NSMF/NSSMFs, transport to NSMF, etc. Endpoints should also include Mid-haul and subsequently Fronthaul (i.e., not just Backhaul alone). This topic requires study of latest 3GPP specs (I am not up to date on this), and a discussion focused around a service provider perspective before implementing a good solution. 

  • Support of mMTC, URLLC and other service types - i.e., multiple CSTs and perhaps also selection of CST 

  • NSI/NSSI selection enhancements – see https://wiki.onap.org/pages/viewpage.action?pageId=100896670. This includes capacity based NSI/NSSI selection. (Implementation Completed)

  • Also, capacity/resource occupancy based NSI selection (item (3) in your list) might involve interaction with each NSSMF to know the feasibility (feasibility check API/interaction defined in TS 28.531).

  • Upon failure of any of the steps in NSI/NSSI creation/resource allocation, ensure a proper clean-up of all resources, AAI entries, CPS entries, etc.

  • Slice modification:

  •  

    • Modification during slice allocation for reuse of existing slice, this in turn, would involve modification of one or more NSSIs.

    • Service modification: Modification of service characteristics (e.g., number of users to be supported, or coverage area, etc.) resulting in modification of the underlying NSI and one or more NSSIs.

  • UUI to allow loading of a map of the geographical region managed by the service provider. The map should be loadable during the deployment (and also later if needed, involving perhaps just a re-deployment of UUI). The map can show rectangular grids with grid numbers which will help the operator to specify the coverage area in a much easier way.

  • Support of Option 2 by NSMF (draft proposal available at https://wiki.onap.org/display/DW/Option+2+support+by+ONAP+NSMF+and+internal+RAN+NSSMF) (Implementation Completed)

  • Slice Profile determination enhancements (when reusing existing NSI) https://wiki.onap.org/display/DW/E2E+Network+Slicing



RAN Slicing

  • Instantiation of RAN NFs and initial configuration : This topic has to be discussed together with the O-RAN team. We should look at using the O2 interface, that was one of the main reasons why it was deferred. Another aspect to be considered is where the CUs/DUs should be instantiated (homing/placement).

  • RAN resource allocation, and the role of Near-RT RIC: At present, ONAP is determining RRM Policy based on some simple rules. It has to be discussed further with O-RAN including the role of Near-RT RIC in fine-grained resource allocation based on high-level guidance by ONAP, and for which cases ONAP has to provide the detailed resource allocation. Nevertheless, RAN resource allocation may optimally be done by OOF, taking into account occupancy level, etc.

  • Decomposition of RAN Slice Profile for consumption by Near-RT RICs: For example, consider a RAN Slice whose components come under the purview of 2 Near-RT RICs. How should the RAN Slice Profile be split (using OOF – based on resource occupancy, traffic trends, etc.) and the relevant parameters passed to Near-RT RIC (e.g., RAN slice throughput) (obviously parameters such as latency does not need decomposition). Some initial thoughts are available at https://wiki.onap.org/display/DW/E2E+Network+Slicing.

  • RAN NSSI modification: For reuse of existing NSSI, e.g., modify coverage area, dimensions (e.g., throughput) or performance attributes (e.g., latency) – this may require resource re-allocation, instantiation of additional RAN NFs, etc.

  • Capacity/resource occupancy based NSSI selection, see also https://wiki.onap.org/pages/viewpage.action?pageId=100896670. RAN NSSI selection enhancements (including feasibility query handling)

  • Capability query handling enhancements (instead of static reply)

  • RAN modeling enhancements

  • Option 2 support



Core Slicing

  • Capacity/resource occupancy based NSSI selection and resource allocation, see also https://wiki.onap.org/pages/viewpage.action?pageId=100896670. Core NSSI selection enhancements (including feasibility query handling)

  • Capability query handling enhancements (instead of static reply)

  • Determining where the NSSI and hence where (which data center) the Core NFs should be instantiated (homing/placement) using optimization techniques. For CNF, existing ONAP solution is likely to require enhancements (inventory source change). See also https://wiki.onap.org/display/DW/E2E+Network+Slicing

  • Re-use some Core NFs (e.g., AMF) while instantiating others (e.g., UPF) when creating a new Core NSSI, or, when reusing existing Core NSSI with modifications

  • Support modification of Core NSSI for reuse

  • Interaction of NSSF (Network Slice Selection Function) in Core with NSMF to know about S-NSSAIs, slice allocation policies, etc.

  • CNF scaling (not just k8s provided mechanism), but based on slice resource occupancy, need to accommodate a new service on the same slice instance, etc.

  • Core NSSI modification: For reuse of existing NSSI, e.g., dimensions, NF placement or performance attributes.



Transport Slicing

  • Supporting multipoint-to-multipoint connectivity for backhaul, and subsequently also for mid-haul.

  • TN NSSI modification: For reuse of existing NSSI, e.g., dimensions, NF placement or performance attributes.

  • Capacity/resource occupancy based NSSI selection and resource allocation, see also https://wiki.onap.org/pages/viewpage.action?pageId=100896670 for some principles, though for TN some aspects may have to done differently. TN NSSI selection enhancements (including feasibility query handling)

  • Capability query handling enhancements (instead of static reply)

  • Support of mid-haul and later fronthaul

  • TN modeling enhancements



Closed Loop

  • Closed Loop at e2e network slice (NSI) level

  • RAN: More closed loop scenarios, with/without active involvement of Near-RT RIC for resource reallocation

  • Transport: Henry had some ideas related to Closed Loop Automation focused on Transport Slicing.

  • Core: Closed Loop scenarios involving scaling, changing the placement of one or more NFs, etc.



KPI Monitoring

  • KPI computation based on PM data coming from multiple NFs from same/different NSSIs (e.g., RAN NSSI latency computation requires data from multiple RAN NFs, e2e NSI latency computation requires data from multiple NFs across RAN/CN/TN NSSIs). Further, if there are multiple NFs of same type belonging to a NSSI, for overall average, data should be considered from all those NFs. In such cases, how will the computation be performed – cache locally until all data inputs is available, how is sequence of computation determined (based on rules?), how is delay/absence of certain data handled, etc.

  • Slice Analysis MS/SO (NSMF) requests KPI computation MS to compute specific KPIs based on the slice type/slice template (refer TS 28.541), or input provided by the operator during service (slice) creation. For this, the e2e flows should be first prepared.

  • Slice Analysis MS requests KPI computation MS to compute specific KPIs based on the Closed Loops that are activated (model-driven per deployment).