Potential requirements impacting OOF in Honolulu release include:are described below.
1. CoverageArea to CoverageAreaTAList mapping
...
- 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.
...
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.
...
3. Enhancements in NSI/NSSI selection
Consider capacity/resource occupancy levels of existing NSI/NSSI.
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