1- Brief Project Overview (brief as it should be known)
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
- Support of new yang models
- SON-Handler MS (DCAE)
3- New or modified interfaces
4- If they are modified, are they backwards compatible?
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