Skip to end of metadata
Go to start of metadata


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

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):



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

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


  • No labels

3 Comments

  1. Comment during the RSCA meeting 2020-07-16:

    A clear definition of the inter working between the open-source projects is required, avoiding duplication of code and avoiding splitting the communities.

  2. Info:

    The O-RAN Alliance has the following guideline with respect to other SDOs: (Source: from O-RAN F2F Paris WG1 Modeling)

    "3GPP is the primary source for m-plane specifications for O-RAN components. 3GPP specifications are referenced in the O-RAN O1 Interface Specification. O-RAN should complement the work of other SDOs, not conflict or compete."

    Such guideline should also apply to O-RAN-SC and other open-source projects (listed above).

  3. regrading the "clear definition of the scope" 

    Proposal: 

    The SMO project defines and describes the solution for specific use cases. Therefore it analysis the use cases and looks for existing open-source functionality to create the solution. It is important to show that the solution is full functional. It is likely that existing open-source functionality does not fit 100% to the requirements of O-RAN and O-RAN-SC so the analysis should include the documentation of gabs, which needs to be address and discussed in the related project. 

    The team should create the necessary component tree for use cases, the documentation for solution deployment and solution operation.  


    Note:

    Imho such project needs team members of solution engineers, cloud engineers, integration engineers and systems/software architects. The team size should not be greater than 6 team member to be efficient and focused.