E2E Network Slicing

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).

Open

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.