Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

1- Brief Project Overview (brief as it should be known)

The objective of this case is to develop an ONAP-based SON platform using the ONAP Optimization Framework (OOF). The use case focuses on the various information models and flows/interfaces between components to enable various SON functions to be realized. It also focuses on platform enhancements such as enhancements to the Control Loop framework (e.g., Control Loop Co-ordination, different types of targets for Control Loops, etc.), enabling ML-based SON, etc.

SON (Self-Organizing Networks) functionality is an essential part of existing 4G mobility networks, and will be even more critical for 5G. SON enables automation to improve network performance and efficiency, improve user experience, and reduce operational expenses and complexity. The objective of the OOF-SON (new name for OOF-PCI) use case is to develop an ONAP-based SON platform using the ONAP Optimization Framework (OOF). We have taken a phased approach since SON is complex, and SON for 5G is still evolving.

We started with the Physical Cell Identity (PCI) optimization SON use case in Casablanca, then added some centralized Automated Neighbor Relations (ANR) aspects in Dublin. Subsequently, adaptive SON functionality was added in Frankfurt release and Control Loop Co-ordination in the context of SON use cases was implemented. ML-based SON functional capability was introduced in Guilin release (wherein the ML model was trained offline). In Guilin, preparatory steps for alignment with O-RAN (CM-Notify, yang models) were taken. In Honolulu, CPS will be used to store all RAN data relevant for SON, and the intention is to go towards new yang models (O-RAN if available, else based on 3GPP TS 28.541 NRM). We also intend to do the ground work for SON-coordination, and as a stretch goal, take up enhancements in Control Loop Co-ordination.  

2- New component capabilities for

...

Honolulu, i.e. the functional enhancements, if applicable

  1. CPS
    • Support of SON models and required interfaces
    • Mapper service for mapping DB queries from OOF, SON-Handler MS and SDN-C to Xpath queries
  2.  CCSDK/SDN-C (SDN-R)
    • Support of new yang models
    • Align with CPS interface
    • Receive CM-Notify over VES interface and process it
  3. SON-Handler MS (DCAE)
    • Align with CPS interface
    • CM-Notify related enhancements (minor)
  4. OOF
    • Align with CPS interface

3- New or modified interfaces

  • Interface to CPS (from SDN-C, OOF and SON-Handler MS)
  • VES message to SDN-C

4- If they are modified, are they backwards compatible?

  • CPS interface is a new functionality, so no backward compatibility issues exist
  • VES message handling by SDN-C is a new functionality, so no backward compatibility issues exist (earlier implementation received Notifications from RAN over netconf which will still work)

6- Interface naming (point to an example)

...