ONAP-based SON for 5G networks: Honolulu Architecture Review
- Swaminathan Seetharaman
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
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
CCSDK/SDN-C (SDN-R)
Support of new yang models
Align with CPS interface
Receive CM-Notify over VES interface and process it
SON-Handler MS (DCAE)
Align with CPS interface
CM-Notify related enhancements (minor)
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)
7- Consumed API from other projects
Project | API Dependency | Notes | APi Specs (Swagger) |
|---|---|---|---|
8- Published API
Project | API | Notes | APi Specs (Swagger) |
|---|---|---|---|
9- Reference to the interfaces.
(Reference to the the swagger.json file(s) whenever possible)
10- What are the system limits?
.
11- Involved use cases, architectural capabilities or functional requirements.
12- Listing of new or impacted models used by the project (for information only).
Identify any High Level Information Model Requirements. See: ONAP R7 Modeling High Level Requirements
Models based on information exchanges from Use Cases
Models documenting existing implementations
Forward looking models that may be implemented in future releases
Describe how exposed APIs are mapped to information models
(list all the relevant Jira tickets)
13-Test plan/Testing Strategy
Unit Testing
Dev-to-Dev Testing and
Integration