/
ONAP Semi-Standalone Project Evolution

ONAP Semi-Standalone Project Evolution

Owned by Byung-Woo Jun
Apr 10, 2025
4 min read

Proposal

  • LFN board approved this proposal

  • we have a full support from Arpit Joshipura and LFN Board 

  • ONAP TSC, ARCCOM, OOM, PTLs and SECCOM need to formalize processes for making semi-standalone projects (architecture, CI/CD, Project Release Cycle, Normalized APIs, Security, documentation)

  • Byung plans to report the ONAP updates to the LFN Board in May.

Our proposals - ONAP TSC and PTL discussed and reached the following conclusions: 

  • ONAP Organization Chart has been created (see below).

  • ONAP Semi-Standalone progress : ONAP TSC and PTL discussed and reached the following conclusions:

  • ONAP projects will be semi-standalone, meaning they will continue to share common governance and recommendations from the ONAP TSC, ARCCOM, OOM and Documentation teams. 

    • The ONAP TSC, ARCCOM and SECCOM will oversee the ONAP projects to ensure best practices, architectural consistency, and strong security. 

    • The ONAP PTLs prefer to retain the existing ONAP governance to minimize overhead.

    • The ONAP Documentation team will continue maintaining official ONAP documentation for now.

  • Each ONAP project manages its features and lifecycle in consultation with the ONAP governance committees.

  • ONAP functions will adopt more descriptive namespaces / prefixes for external clients. The final decision will rest with the respective ONAP PTLs.

  • OOM currently provides many useful services for ONAP projects. As a result, common services and OOM would be included by default. 

    • Telecom operators may adopt alternative integration options. For example, if they may use their own security, secure communications and/or CD solutions (ArgoCD, Flux), and such choices will not be precluded. 

    • The ONAP community plans to provide comprehensive documentation to support these deployment and integration options.

    • OOM Support includes: Strimzi, Istio, Keycloak, ONAP CI/CD pipeline, ArgoCD and Flux, Project build, Helm Chart repos.

    • The current common helm chart repository needs to be separated by project; further discussion is needed with PTLs.

    • DT is enhancing the OOM scripts to be aligned with their production-ready environment, but they are still open-source based.

    • DT is also contributing both ArgoCD and Flux CD solutions for individual ONAP component deployments, which are integrated into ONAP CI/CD pipelines.

  • Currently, ONAP project functions are decoupled from security, secure communication and deployment, offering flexibilities for operators.

  • ONAP projects will continue to be modularized, allowing sub-components to be selected at or after build time – offering greater integration flexibility based on operator use cases.

    • ONAP projects shall be lightweight, flexible and extensible in configuration based on the desired features

  • ONAP projects should minimize interdependencies across components.

    • Dependencies for SDC, AAI and DCAE and MultiCloud will be analyzed.

    • The respective ONAP PTLs will also examine interdependencies among the Portal-NG, UUI, SO, Policy, CPS and CCSDK/SDNC.

  • Additional ONAP use cases and AI capabilities are being discussed among the ONAP TSC and PTLs.

    • China Mobile and China Telecom have contributed GenAI-related work, but their models and mechanisms are not open.

    • Discussions are underway around Open AI Models and frameworks, aligned with LFAID’s MOF and MOT initiatives.

    • ONAP PTLs were asked to explore possible AI integration into their projects

    • Discussions are ongoing on how to create solutions that leverage individual ONAP component functions.

      • China Telecom has forked a “Lightweight ONAP platform” for its 6G research.

      • China Mobile plans to contribute a new MaaS (Model As A Service) AI capability to the ONAP Paris release.

  • DT and OdineLabs/TurkCell have chosen ONAP components for service orchestration.

    • In the DT cases, selected ONAP components are being included in their O-RAN-TOWN project.

  • O-RAN SC also plans to adopt ONAP functions.

    • Note that O-RAN SC would be very selective about the code from ONAP, according to O-RAN SC SMO PTL..

Background

 

The concept of elevating ONAP modules to semi-standalone entities was presented to the board and got positive feedback. One request that did come up was to clarify the evolution of the integration tests that are currently part of the ONAP-wide release process (will they still exist in some form to ensure interoperability between the independent modules?). The next step would be executing the necessary changes in the ONAP CI/CD system. I see that @Byung-Woo Jun already has a sessions planned for the ONAP DTF Day (https://lf-onap.atlassian.net/wiki/x/mICKBg ) to discuss the next level of details. @LJ Illuzzi and I will of course support from the LF side.  

  • Also, credits go to Ciaran Johnston and Christian Olrog 

  • Byung-Woo Jun,

At the ONAP DTF days, I plan to present the ONAP TSC roadmap and Architecture evolution, covering this concept. Working with DT and other ONAP participating companies, I have outlined how ONAP will enable the individual build and deployment of ONAP components under the ONAP Streamlining evolution; i.e., ONAP already supports these capabilities.

The current OOM enhancements led by Andreas Geissler for ONAP CI/CD and ONAP architecture, leveraging Argo CD were tested during the Oslo release by DT and ARCCOM. Now, DT plans to contribute to ONAP CI/CD further by using both Argo CD and Flux during the Paris release. Additionally, China Telecom, China Mobile and DT have integrated several core ONAP components, referred to as Lightweight ONAP solutions, for their 5G and upcoming 6G.

Over the past couple of years, under the ONAP Streamlining evolution led by me (Byung), we have established a solid foundation, which has proven to be valuable.  

Furthermore, ONAP TSC and ARCCOM have already discussed the possible integration solutions by leveraging individually built ONAP components. We are currently in the process of formalizing integration procedures and developing use cases for higher-level solutions.  Additionally, I proposed the Runtime CI/CD for ONAP, and it will be part of my ONAP DTF Days presentations.

I fully agree with this direction, and we are proud of the foundational work achieved through this evolution. More to come…  We have seen the future 😊

I plan to present the evolution to the ONAP DTF Days, and I look forward to collaborating with you all.

  • Kudos to all ONAP contributors!!! Thanks!

  • We need documentation for formalizing this new evolution. such as each each project documentation, API, security, release cycle, etc. 

 

Related content