PROJECT PROPOSAL  Service Management and Orchestration (SMO)

O-RAN Software Community Releases Cherry, Dawn

Project Name:

• Proposed name for O-RAN SC project: Service Management and Orchestration (SMO)

• Proposed name for the repository: smo

Project description:

The term “SMO” refers to its definition by the O-RAN Alliance. The primary goal of the SMO project is to integrate different software artifacts for existing open-source projects creating a fully functional open-source Service Management and Orchestration (SMO). It is intended to find and document gaps in open-source compared to the O-RAN specifications of a SMO. Specification proposals and implementations showing how to address such gaps will be proposed to related O-RAN working groups. The objective is to provide documentation and software implementation of integration tested SMO deployment interacting with O-RAN ManagedElements based on the use cases defined by O-RAN Alliance WG1 UCFG.

The SMO project has strong dependencies to

• O-RAN-SC projects NON-RT-RIC, OAM, INT, SIM and DOC and to

• O-RAN Alliance Working Groups 1, 2, 3 and 6.

• Refer to OSC wiki for work completed within previous releases: https://wiki.o-ran-sc.org/display/OAM/SMO+-+Service+Management+and+Orchestration

It is assumed that modern implementations of a couple of Linux Foundation Projects are considered creating the function of a SMO as defined by O-RAN Alliance
(in alphabetical order):

• Acumos

• Akraino

• Cloud Native

• gRPC

• HELM

• kubernetes

• Let’s-encrypt

• LF Networking

  • ONAP

  • OPNFV

  • OpenDaylight

• OSM

• OvS

• and many more …

The SMO project will describe and document the instantiation of different SMO deployment options:

• SMO-Dev
  A SMO instance which focus on developer experience, used by O-RAN-SC developers.
  (Note: if appropriate, artifacts (code, doc) could move OAM project to SMO)

• SMO-MVP “Minimum Viable Product” (pro for Cherry)
  A light-ware SMO instance mainly used for module testing. It should include O-RAN-SC simulators to show and validate the entire O-RAN functions
  (Note: if appropriate, artifacts (code, doc) could move from Non-RT-RIC and OAM project to SMO

• SMO-full (future releases)
  A full functional O-RAN-SC SMO instance as reference implementation for commercial products, including “one-click” deployment, geo-redundancy, ...)

Scope:

The following features are in scope for the SMO project within O-RAN SC release Cherry:

Demonstration of Pre-O2 LCM feature

• Cherry Application LCM Step 1 - Create Application Package

• Cherry Application LCM Step 2 - Package Validation

• Cherry Application LCM Step 3 - Catalog Package

• Cherry Application LCM Step 4 - Create Config

• Cherry rAPP Deployment Scenario  (candidate for OSC rel D "Dawn")

• Cherry xAPP Deployment Scenario (candidate for OSC rel D "Dawn")

• Cherry Specifications, YANG Modules, NonFunctional

The implementation of this use case will demonstrate what application developers need to do in order to onboard their application to the SMO. It will also provide orchestration requirements for an SMO implementation in order to manage an onboarded application through its Life Cycle.

• SMO-Dev (for developers only)
  Update existing A1 (Rest), O1 (NetConf, VES, FTPes) so, Pre-O2, ModelCatalog, ServiceConfig, VirtualInventory and OTF test harness

• SMO-MVP “Minimum Viable Product” (candidate for OSC rel C "Cherry")
  In addition to SMO-dev, a light-ware SMO instance mainly used for facilitating module testing using OTF scripts. It should also include O-RAN-SC simulators to show and validate the entire O-RAN functions. Stretch goal: Inclusion of ML training for xApps and rApps that use AI/ML components in the SMO.
  (Note: if appropriate, artifacts (code, doc) could move from Non-RT-RIC and OAM project to SMO)

• SMO-full (candidate for OSC rel D "Dawn")
  A full functional O-RAN-SC SMO instance as reference implementation for commercial products, including “one-click” deployment, geo-redundancy.

Please see (draft - will be updated)

SMO in O-RAN architecture – Source: O-RAN-SC OAM

Resources:

Project Technical Lead (PTL): multiple candidates

Names, gerrit IDs, and company affiliations of the committers:

to be defined – does this project need gerrit/nexus? Or are wiki and doc sufficient?

Names and affiliations of any other contributors (in alphabetical order):

to be defined – does this project need gerrit/nexus? Or are wiki and doc sufficient?

Key Subproject Facts

Subproject Name:

JIRA subproject name: smo

JIRA subproject prefix: smo

Repo name:

smo/…

Lifecycle State: incubation