Exploring Interactions Among SMO-related Projects in OSC and ONAP

Slide Note
Embed
Share

Coverage of SMO functionality is increasing in OSC projects with strong overlap between OSC and ONAP for SMO-related functionality. Consensus at TOC/TSC level in OSC and ONAP to align with trends in SMO-related discussions in O-RAN Alliance, especially WG1 SMO Decoupled Architecture TR. Efforts to avoid duplication and improve synergy and collaboration between OSC and ONAP by building on existing work and enhancing interworking and alignment across various components. Ongoing work in O-RAN WG1 on Decoupled SMO Architecture and decomposition of SMO functionalities into Service Based Architecture, SMO Functions, and SMO Services. Recommendations for implementing SMOS in SMO SBA representation.


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.



Uploaded on Apr 17, 2024 | 5 Views


Presentation Transcript


  1. OSC/ONAP SMO Framework Exploring interactions among SMO-related projects in OSC and ONAP June xx, 2023 Incorporating ideas and support from several people, including: Andrea Buldorini, Rittwik Jana, John Keeney, David Kinsey, Seshu Mudiganti, Timo Perala, N. K. Shankar, Martin Skorupski, Joseph Thaliath

  2. Summary Coverage of SMO functionality is increasing in OSC projects Strong overlap between OSC and ONAP for SMO-related functionality There is consensus in OSC and ONAP at TOC/TSC level: SMO-related work in OSC and ONAP should align with trends in SMO-related discussion in O-RAN Alliance, especially WG1 SMO Decoupled Architecture TR Avoid duplication, improve synergy and collaboration between OSC and ONAP Build on existing OSC/ONAP work improve interworking and alignment oam (o1,ofh-mp), sdn-c, ves collector, pm handler aimlfw, dmaap/kafka, policy, cps db non-rt-ric (a1,r1,rapp) smo (o2), so intent Select end-to-end application use cases to define end-to-end flows Identify gaps and future direction

  3. O-RAN WG1 Decoupled SMO Architecture Work Item Figure from TR section 4 (July 2022 WG2 view) Active discussion and ongoing work in O-RAN WG1 ATG on Decoupled SMO Architecture Decomposition of SMO functionalities Service Based Architecture (SBA) SMO Functions (SMOF) SMO Services (SMOS) Output: Decoupled SMO Technical Report Links: https://oranalliance.atlassian.net/wiki/download/attachments/22174764 45/O-RAN-WG1.Decoupled-SMO-Architecture-TR-v01.00.09.zip?api=v2 https://oranalliance.atlassian.net/wiki/spaces/UCOA/pages/2217476445/ ATG+Draft+Specifications https://oranalliance.atlassian.net/wiki/spaces/UCOA/pages/2513043516/ Decoupled+SMO+Technical+Report+TR+CR+Tracker Figure from Draft TR section 6 (Recommendation)

  4. Recommendation in O-RAN WG1 Decoupled SMO Architecture TR-R003-v01.00.09 Section 6.2 Recommended Solution The SMOSs identified in clause 5 of this document are represented in a service-based architecture in the figure 6.2.1-1 below. Figure 6.2.2 -1: SMOSs in the SMO SBA representation

  5. OSC and ONAP projects related to SMO (draft, expect changes) Relevant projects to be placed smo-pkg aimlfw intent int acm policy cps a&ai? oof? dcae? non-rt-ric idam Notes: Figure is meant to explore alignment to O-RAN architecture Each red/blue label is an osc/onap open source project/component We may/do not have or need 1:1 mapping between projects and architecture blocks dmaap/kafka smo, so oam ves sdn-c non-rt-ric aimlfw ran-sim inf sim sim Figure 6.2.2 -1: SMOSs in the SMO SBA representation

  6. Example of SMO interaction: AIMLFW Example of SMO interaction: AIMLFW 1AIMLFW Non-RT RIC portal-aiml-dashboard AWMF-TM Assit rApp ML rApp USER ATHP AIHP AIMLFW needs to exchange data with rApp/Non-RT RIC via DME SDK QoE SDK Kserve Adapter Kubeflow Adapter - Model Storage Training Pipeline - Feature Store IPS - Kserve Data Extraction DME TPS - Kubeflow Model storage (Leofs) RAN NF data is received over O1 by OAM (RAN OAM NF) Kafka Data Lake (Influx DB) O1 Termination Near-RT RIC AI/ML can also be applied for O2- related data AIMLFW AI/ML Framework AWMF AI Workflow Management Function TM Training Manager Assist xApp ML xApp TPS Training Platform Service (e.g. Kubeflow) AIHP ATHP AI Training Host Platform IPS Inference Platform Service (e.g. Kserve) Kserve Adapter SDL AIHP AI Inference Host Platform IPS - Kserve (Influx DB) 1Location of AI Training functions is not fixed and may vary according to usecase. 6

  7. SMO interactions: Energy Savings (ES) scenario Objective: Select a use case scenario to define call flows, identify gaps, and provide guidance for synergy/collaboration among open source components (not to implement a fully functional use case) Assume one or more rApps for ES use case Use FOCOM/NFO and O2 to configure O-cloud deploy RAN NFs Use oam and rApp(s) to configure RAN NF and get RAN data using O1 Assume AI/ML functions/services are trained and available Use rApp(s) to analyze RAN data Reconfigure RAN NF as needed via O1, A1 to optimize energy Pause/restart RAN NF as needed via O2-dms to optimize energy Modify cloud resources (e.g., cpu performance, turn off) via O2-ims to optimize energy

  8. Feedback from OSC to O-RAN 1. OSC is seeking to align SMO-related work with: O-RAN Architecture TS and TR Decoupled SMO Architecture TR work - relevant for ongoing trends MVP-C Use Cases to highlight interactions between components Is it correct to use SMO-DEC TR section 6.2 Recommended Solution for WG1 as basis for SMO architecture? How will AI/ML functions/services be included in SMO architecture? How will policy functions and co-ordination across SMO components (e.g, different rApps, different actions on same interface) included in SMO architecture? Is MVP-C Energy Savings Use Case a good choice for a comprehensive scenario to study interactions between (all) SMO components? Any comments on options to implement database, inventory? 2. 3. 4. 5. 6.

  9. OSC/ONAP SMO Framework Objective: Keep track of ONAP/OSC projects and components related to SMO Define/study end-to-end application use cases, sequence flows involving multiple components Identify interfaces, apis, missing functionality Alignment with O-RAN Architecture Maximum synergy/collaboration in ONAP and OSC code development Process 1) Socialize among stakeholders 2) ONAP: Present ONAP SMO Framework Use Case to ArchCom 3) OSC: Present in RSAC/TOC discussions

  10. ONAP Release M plan (draft) Develop overall architecture/guidance for SMO-related work Select interaction scenario based on end-to-end application use case Objective is to highlight interaction Aligned with O-RAN MVP-C use case trends Suggestion: Energy Savings scenario Output: Wiki pages/documents, sequence diagrams Feedback to O-RAN WG as needed Explore feasibility of simple interworking

  11. Background presentations

  12. ONAP/OSC Synergy Discussion presented in RSAC in March 2023 ONAP and O-RAN SC John Keeney, Seshu Mudiganti, Timo Perala, N. K. Shankar, Martin Skorupski March 21, 2023

  13. Summary & Objective O-RAN SC and ONAP have common areas of interest This is a good time to improve collaboration and synergy Objective of this presentation: Provide a high-level overview List common areas of interest Highlight areas of ongoing good collaboration Identify new areas with potential synergy Discussion priorities, next steps

  14. O-RAN SC and ONAP O-RAN Software Community (OSC) (https://o-ran-sc.org/ ) Part of Linux Foundation (LF) The O-RAN Software Community (SC) is a collaboration between the O-RAN Alliance and Linux Foundation with the mission to support the creation of software for the Radio Access Network (RAN). The RAN is the next challenge for the open source community. The O-RAN SC plans to leverage other LF network projects, while addressing the challenges in performance, scale, and 3GPP alignment. ONAP (https://www.onap.org/ ) Part of Linux Foundation (LF) and Linux Foundation Networking (LFN) ONAP is a comprehensive platform for orchestration, management, and automation of network and edge computing services for network operators, cloud providers, and enterprises. Real-time, policy-driven orchestration and automation of physical and virtual network functions enables rapid automation of new services and complete lifecycle management critical for 5G and next-generation networks ONAP work is directly relevant to anything related to O-RAN SMO (Service Management and Orchestration)

  15. Service Management and Orchestration functions of SMO have strong overlap with ONAP Operators are using ONAP components for SMO This figure is from early days of O-RAN (~2020/21) using ONAP concepts (e.g., DCAE, SO, Policy, OOF ..) Recently posted by Alex Choi in article about importance about SMO (around March 9, 2023) (https://www.linkedin.com/posts/alex-jinsung-choi-48a8b61_oran-openran-oranalliance-activity-7039638269231263744-3Lqj?utm_source=share&utm_medium=member_desktop )

  16. Southbound interfaces from SMO to RAN: Specified by O-RAN ONAP projects have goal to align with O-RAN specs Figure 5.1-1: High Level Architecture of O-RAN (From O-RAN.WG1.OAD-R003-v08.00)

  17. ONAP SON Use Case Example Aligned to O-RAN O1 and A1 Configuration (O1) and Policy Guidance (A1) from SMO to RAN Data Analysis, SON Algorithm SDN-R (SDN-C) SON Handler MS A1 PMS Simulated RAN (O-RAN) Policy A1 OOF SLI FM/PM to m mS A1 Policy O1 RAN-Sim Control Loop CM Notifn FM/PM DB Config Change A1 RAN App DES MS TBDMT O1 VES Coll Data Lake CU/DU O1 DMI CM update to CPS DB FM, PM, CM Info from RAN NCMP DMaaP REST API CPS DB O1 A1 Public

  18. O-RAN WG1 ATG Decoupled SMO TR will show separation of SMO functionalities Ongoing work Service Based Architecture (SBA) SMO Functions (SMOF) SMO Services (SMOS) Relevant to ONAP and OSC design choices Figure 4.1-3: SBA representation of the documented SMO services in July 2022 specifications (From O-RAN WG1 Decouple SMO Architecture TR v01.00) Editor s Note: 1) The naming of the interfaces is to be further analyzed and refined in section 5 and 6. 2) The figure needs to be reviewed with WG2 for non-RT RIC architecture part, so it might be further updated if needed, as per latest agreed version with WG2. 3) Though the figure does not explicitly illustrate, an objective would be to represent a common set of possible abstracted SMOSs across SMOFs. For example, it would be desirable to represent a common set of SMOSs for FM to query and acknowledge Faults, as well as an associated common information model for fault LCM, irrespective of whether that Fault originates in the O-Cloud Resources Management and Orchestration Services SMOF or the RAN NF OAM Services SMOF.

  19. ONAP/OSC Harmonization Ongoing effort among group of stakeholders seeking to find synergies Good collaboration - especially for o1/ofh-mp, oam, sim, non-rt-ric, a1 Weekly calls: Wed 12 noon ET Approach: Share information, review status, seek synergy Avoid duplicate effort, re-use code, use one repo when possible Stay flexible and accommodate variations of modules New areas are coming up: O2, R1, intra-SMO interfaces, AI/ML Harmonization effort has largely been from ONAP side to work with OSC Good time to review and establish joint objectives! (ONAP TSC, OSC TOC) Operators interested in O-RAN are using ONAP components Objective today: Review and find/prioritize common areas of interest

  20. Common ONAP/OSC areas O1 and A1 O1 / OFH-MP interfaces (RAN NF OAM SMOF and SMOS) -> WG10, WG4 Good ongoing ONAP/OSC harmonization and collaboration since early days CU/DU/RU yang model development and refinement Strong support in OSC sim and ONAP RAN-Sim simulators O1 FM/PM/CM development and refinement ONAP use cases: Control loops, 5G SON, Network Slicing etc. Feedback to O-RAN WGs Would be helpful to make release timelines and versions better aligned. A1 interface (non-rt-ric related SMOF/SMOS) -> WG2, WG10 Good ongoing ONAP/OSC harmonization and collaboration since early days SDN-R/CCSDK to A1-Termination ONAP projects exploring rApp and control loop designs 5G SON use case, rAppification etc. ONAP RAN-Sim extended to provide ran-app abstraction and A1 Termination We can build on existing collaboration model

  21. Common ONAP/OSC areas O2 O-Cloud/NF orchestration and management is relatively new area for open source O2-ims (O-RAN FOCOM-related SMOF/SMOS) -> WG6 Cloud domain orchestration and management ONAP multi-VIM O2-dms (O-RAN NFO-related SMOF/SMOS) -> WG6 NF orchestration and management O-RAN WG6 has ETSI and K8s profiles ONAP NF orchestration and management more relevant for K8s (ASD) profile ? Very timely area for harmonization of open-source efforts Worthwhile to also consider synergy/sharing with other projects Nephio (LF), O-RAN OSFG, ?? Choose use cases needing co-ordination across O2-ims/O2-dms/O1 Contribute to WG1/6/10 re. interaction between FOCOM, NFO, RAN NF OAM NEW AREA NEW AREA

  22. Common ONAP/OSC areas Non-RT RIC rApp, Applications, R1 interface: WG2 (WG10, app mgmnt, WG1) ONAP use cases for applications which manage RAN (pre-rApp, pre-R1) Good amount of work in OSC Already reusing ONAP functions as part of rApp management/LCM rAppification - Ongoing effort to leverage ONAP control loops, Policy, microservices, use cases, and align with O-RAN R1 interface SMO Policy Functions -> WG2 (WG10, app mgmnt, WG1) ONAP has a Policy Enforcement Function to provide policy-based co- ordination across applications and interfaces No clear placeholder in current O-RAN SMO architecture or OSC rApp might use multiple SMO services rApp might contains Policies (ref work in ONAP ACM / App manager) Should co-ordination across rApps and interfaces be an SMO capability? NEW AREA NEW AREA

  23. Common ONAP/OSC areas Intra-SMO, Northbound Several integral ONAP components are intra SMO or northbound/external Service management, orchestration, data handling, LCM etc. part of ONAP charter End-to-end implementation can highlight design/scalability/operational issues Can be relevant to SMO southbound interfaces e.g., modelling Key takeaway: Consider reusing existing work when use cases grow to new areas Service Orchestration, Service Design, Data Handling (SO, SDC, DCAE) Higher level than Cloud Orchestration and NF Orchestration Creation and orchestration of SMO Services as well as End-to-end Services which need to be instantiated to implement a use case Inventory (resources, models, connections), Configuration database ONAP has A&AI for resource/NF/service inventory and CPS DB for NF configuration e.g., CPS DB using O-RAN yang model for CU, DU, RU config Northbound interfaces (Portal etc) Intent-based networking NEW AREA NEW AREA

  24. Common ONAP/OSC areas Overall AI/ML WG2 Previous AI/ML work is generic without specific role for Non-RT and Near-RT RIC. Implications on implementation choices for rApp, database, data exposure etc. SMO Architectural choices -> WG1 Consider SMO Functions/SMO Services approach in implementations Provide feedback to WG1 promote efficient approaches Design choices can enhance relevance of open-source efforts to industry End-to-end use cases -> WG1, OSC Consider choosing common use cases in OSC and ONAP Consider end-to-end use cases which highlight inter-operability interfaces Security WG11 Share/use best practices - interfaces, design, system implementation, code design etc Success example: Sharing of best practice for logging from ONAP to O-RAN WG11 Simulation -> OSC Ongoing effort to leverage/harmonize work in OSC sim and ONAP RAN-Sim etc. OSC oriented towards CU/DU functions, ONAP oriented towards use case NEW AREA NEW AREA

  25. OSC AIML example of interworking between OSC projects OSC AIMLFW OSC AIMLFW Update f Update for TOC or TOC Joseph Thaliath May 11th, 2023

  26. Current AIMLFW Architecture Flow Current AIMLFW Architecture Flow 1AIMLFW Non-RT RIC portal-aiml-dashboard AWMF-TM Assit rApp ML rApp USER ATHP AIHP SDK QoE SDK Kserve Adapter Kubeflow Adapter - Model Storage Training Pipeline - Feature Store IPS - Kserve Data Extraction DME TPS - Kubeflow Model storage (Leofs) Kafka Data Lake (Influx DB) O1 Termination Near-RT RIC AIMLFW AI/ML Framework AWMF AI Workflow Management Function TM Training Manager Assist xApp ML xApp TPS Training Platform Service (e.g. Kubeflow) AIHP ATHP AI Training Host Platform IPS Inference Platform Service (e.g. Kserve) Kserve Adapter SDL AIHP AI Inference Host Platform IPS - Kserve (Influx DB) 1Location of AI Training functions is not fixed and may vary according to usecase. 28

  27. AIMLFW Overview AIMLFW Overview Release H Status Diversify training data source for Training host (DME Integration testing in progress) Demo of feature group creation with DME data source Kserve adapter (Code commits in progress ) Kserve adapter for Near-RT RIC Training pipeline Enhancement (Completed) Provide sample pipelines by default AIMLFW feature enhancements (Code commits in progress ) Options for edit, retrain and delete training jobs O-RAN Alliance Alignment Release I Plan 29

  28. O O- -RAN Alliance Alignment RAN Alliance Alignment Working group/Committee Subgroup/Meetings/Topic Further Details WG2 WG2 Non-RT RIC Architecture Deriving requirements for AIMLFW AI/ML Draft meeting Monitoring ongoing AIML services discussed https://oranalliance.atlassian.net/wiki/ spaces/NonRTRIC/pages/2635628700/ AI+ML+Drafting+Meeting WG3 Near-RT RIC architecture https://oranalliance.atlassian.net/wiki/spaces/Near RTRIC/pages/2709356787/AI+ML+in+O-RAN CMCC-2023.2.6-WG3-AIML-in-O-RAN- F2F-v02.pptx CMCC-2023.04.18-WG3-CR-001-AIML Support Function-v02.docx AI/ML support consists of 4 services: Data Pipeline, Model Management, Training and Inference WG1 https://oranalliance.atlassian.net/wiki/download/a ttachments/2217476445/O-RAN-WG1.Decoupled- SMO-Architecture-TR-R003.v01.00.08.docx?api=v2 MVP-C AIML Work item https://oranalliance.atlassian.net/wiki/spac es/MVPC/pages/2594832816/MVP- C+AI+ML+for+O-RAN April 07, 2023 O-RAN Alliance - Working Group 10 30

  29. Release I Plan (Ongoing) Release I Plan (Ongoing) Following are high level topics to be considered: Model deployment options Training Pipeline abstractions Integrated install with Non-RT RIC/ Near-RT RIC/SMO Model Performance monitoring Model validation Advanced Feature selection Model services Advanced retraining options AIMLFW installation optimizations Integrate Non-RT RIC and Near-RT RIC AI/ML usecases https://jira.onap.org/browse/DCAEGEN2-3067 To prioritize and select based on brainstorming and feedback 31

  30. Open topics Open topics Access to data available at Near-RT RIC for training models in SMO. Deployment of ML model Will it be considered as xApp or rApp deployment? Will it provided as service from platform? Will model be integrated within xApp and rApp and will not require support from inference platforms? Model formats Training function inputs 32

Related


More Related Content