Versions Compared

Old Version 2

changes.mady.by.user user-59b16

Saved on

compared with

New Version Current

changes.mady.by.user user-30c9d

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Cherry Release (Dec 2020)

Skip to end of metadata

Go to start of metadata

Cherry release page for the O-RAN Software community   

Welcome to the Cherry D release page for the O-RAN Software community          

This page contains all the information specific to the Cherry release

See Requirements and Software Architecture under Committees and Projects for more details on current activities.

Second release capabilities include contributions under the following projects:

...

community.

To download the source code for the D release, please check the section "D release source code, container images and deployment instructions" at the end of each subproject table below for the subproject that you are interested in. The same section - if applicable - also includes a reference to the container images that make up the D release and to deployment instructions.

General D release container image list for all subprojects. 

Table of Contents
        


Near-Real-time RIC X-APPs (RICAPP)

...

Primary Goals: Expand the community working on open source xApps for O-RAN SC. Enhance the set of open source xApps in support of the R-SAC use cases (traffic steering, health check, life cycle management) as well new use cases. Update and enhance existing xApps to take advantage of the new features in xApp SDK (implemented by the xApp frameworks in C++, go, and python).

D release highlights (7-7-21):

  • Expanded set of xApps from expanded community: D release includes xApps from HCL (AD, QP, Bouncer), Samsung (KPI, HW-python, HW-go), ChinaMobile (LP), Parana Technical University (TS), and AT&T (HW, MC).
  • AD xApp implements true ML-based anomaly detection where the ML-model is trained using data from Viavi E2 simulator and then at runtime, AD reads time series data from the inFlux (DB new RIC platform component) and raises anomaly alarms.
  • QP xApp implements for the first time true ML-based throughput prediction trained using data from Viavi simulator. QP receives prediction request for a set of UEs, determines the current UE metrics and current neighbor cells by reading the inFlux DB and provides prediction of the throughput prediction in the current serving cell as well as the neighboring cells. Note that the current QP includes the functionality previous embedded in the separate QP-driver xApp.
  • TS xApp has been extended to receive anomaly detection messages and trigger predictions request based on these messages. It is also extended to make a call to Viavi simulator (REST based call while waiting for E2SM RC) to trigger UE handover.
  • The AD, QP, and TS xApps have been integrated to implement an anomaly detection driven traffic steering use case.
  • KPIMON xApp now implements E2SM KPM 2.0.3 - when an E2 simulator is available that implements that SM, the KPIMON flow can be tested (likely E Release) and integrated with the rest of the use case.
  • The new LP xApp introduces a load prediction capability - this new xApp will be integrated with the traffic steering use case in E Release
  • The new demo (hello world) xApps HW-python and HW-go introduce the initial versions of xApps to demonstrate how all RIC features can be utilized from xApps written in python and go.
  • Bouncer xApp has now been properly introduced as an xApp in the RICAPP project - it will allow the performance benchmarking of the RIC platform (latency of INSERT-CONTROL loop, number of E2 Nodes supported).
  • The HW (C++) and MC xApps include minor updates.
  • Image list: can be found here.
  • Instructions for testing the xApps: can be found here....

PTL: Matti Hiltunen

Jira: Count of Epics, User Stories, Tasks, and Issues:  165 issues

Status (5-25-21): 

D Release status

  • New xApps:
    • Bouncer xApp (HCL, C++): RIC performance measurement xApp - in conjunction with the appropriate E2 Sim, can test E2 control loop latency (INSERT-CONTROL) as well as the scalability of the RIC with regard to the number of E2 Nodes supported.
    • LP (Load Prediction, ChinaMobile, python): Initial version of a cell load predictor.
    • HW-P (Hello World - Python, Samsung): A python based demo xApp that demonstrates how an xApp can use the RIC platform features in python.
    • HW-G (Hello World - go, Samsung): A go-based demo xApp that demonstrates how an xApp can use the RIC platform features in go.
  • Improved xApps:
    • AD (Anomaly Detection, HCL, python): A ML-based real-time anomaly detection using KPI data populated in inFlux DB.
    • KPIMON (Samsung, go): Improved version implements E2 SM KPM 2.0.3 version and stored collected data in time series DB (inFlux)
    • QP (QuE Predictor, HCL, python): A ML-based predictor of UE's throughput if it was handed over to a neighboring cell. The D release version finally uses a ML-trained prediction model and includes the functionality previously provided as a separate QP-driver xApp.
    • TS (Traffic Steering, UTFPR, C++): Extended version of the TS xApp that now receives anomaly detection messages, requests QoE prediction, and issue control operation to request a UE handover.
  • Together, AD, QP, and TS xApps and Viavi E2 Tester, implement a use case where anomaly detection is combined with QoE prediction and traffic steering action to move the affected UEs to a different cell.

D release source code, container images and deployment instructions

Each repository has a branch named "dawn" that can be accessed using git. For example, the source code for the AD xApp can be retrieved using  "git clone --branch dawn "https://gerrit.o-ran-sc.org/r/ric-app/ad". The other xApps in the D release can be found at ric-app/qp, ric-app/ts, ric-app/lp, ric-app/hw, ric-app/hw-go, ric-app/hw-python, ric-app/mc, ric-app/bouncer, and scp/ric-app/kpimon. Note that the other ric-app repos are obsolete.

Note that this branch is in maintenance and all new development is done in branch "master".

In order to deploy the D release xApps,  you can re-use the pre-created container images as defined here and the instructions on testing the xApps can be found here.


Near-

Get Cherry

Documentation

Cherry Release Timeline

Cherry Timeline

Near-Real-time RIC X-APPs (RICAPP)

Primary Goals: Expand the community working on open source xApps for O-RAN SC. Enhance the set of open source xApps in support of the R-SAC use cases (traffic steering, health check, life cycle management) as well new use cases. Update and enhance existing xApps to take advantage of the new features in xApp SDK (implemented by the xApp frameworks in C++, go, and python).

Cherry release highlights (12-08-20):

  • Expanded set of xApps from expanded community: Cherry release includes xApps from AT&T (TS, QP-D, QP, HW, MC), Samsung (KPIMON), and HCL (AD).
  • Traffic steering use case has been extended to include data collection via E2 (using pre-spec extensions to the E2 KPM SM) by the KPIMON xApp. The KPIs used by the traffic steering use case are generated by Viavi RAN simulator.
  • ML-based xApp: The AD (Anomaly Detection) xApp from HCL uses ML-based algorithm for anomaly detection.The AD xApp is losely integrated with the TS use case in Cherry b ut a tigher integration is planned for Dawn.
  • The demo HW (HelloWorld) xApp now has a full implementation of the HW E2 SM including subscription, indication and control as well as C++ class wrappers for all the E2 messages related to HW E2 SM.

PTL: Matti Hiltunen

Jira: Count of Epics, User Stories, Tasks, and Issues:  165 issues

Status (9-8-20): Integration of KPIMON in progress, new xApps under design, QP-Driver updated to use new SDK for alarms and metrics.

Status (9-30-20): Samsung taking over integration and testing of KPIMON; Viavi simulator producing data - an update in the data content expected this week (UE throughput, UE ID); ML-model building started based on Viavi and other simulated data (QP, AD); new xApp repos requested (Signal Storm Protection, Load Prediction); bug fixes to HelloWorld, E2 AP/SM abstraction layer underway for HelloWorld.

Status(11-17-20): ML-xApps (QP,AD) code committed - dealing with merge issues. End to end testing and bug fixes underway.  E2AP/SM abstraction work for HelloWorld (C++) xApp completed. New repos created for HelloWorld in go and python (for Dawn).

Near-

Real-time RAN Intelligent Controller Platform (E2 Interface) (RICPLT)

Mission:

 Better manageability of, for example, E2 connections, the RIC platform as well as xApps via the xApp frameworks.

Primary Goals: Support operator-initiated health-check via E2 and be able to close all current or reject all future E2 connections. More manageability of the RIC platform and xApps, including, for example, platform statistics from E2 and A1 and more capabilities in the language-specific xApp frameworks and SDL (shared data layer).

Cherry release highlights (2020-12-01): We implemented the operator-initiated E2 connection health check. There is now more alignment in the level of support of various xapp framework and SDL features in python, c++ and go. For example: SDL (shared data layer) now also supports notifications in Python. The xApp framework for C++ now supports alarms, statistics and configuration management. xApps can now use SDL notifications for changes in connection states of E2 nodes. By confirming route updates before continuing we increased robustness in management of internal routes. We now also support using existing non-E2 protocols for communication with RAN. We also adapted the scaling implementation for E2 termination to the reversal of E2AP connection initiation introduced by E2AP 01.00. The E2 manager can now reject new E2 connections requests in addition to closing all E2 connections. E2 and A1 now provide platform statistics for their connections. 

Detailed list of JIRA items that we worked on in Cherry (requires LinuxFoundation login): Remaining open items: link  (1 items). Items that are marked as done: link (23 items). Moved out from Cherry: link (24 = 13 stretch goal items and 11 "normal items").

PTL: Thoralf Czichy

Status 2020-12-11:

HCL: RIC-360 done.

ATT: (e-mail sent): RIC-359 (likely postponed)

Status 2020-12-08:

HCL: DONE: RIC-149 (=RIC-362), RIC-509, RIC-109.  // delayed into Dawn: RIC-150 // RIC-360: Code submitted & Merged CLOSE once gerrit review in RIUC-678 is done (see open review https://gerrit.o-ran-sc.org/r/c/it/dep/+/5237)

ATT: (e-mail sent): RIC-359 (likely postponed)

Status 2020-11-24:

HCL: RIC-149, RIC-150, RIC-360, RIC-509. Ask if RIC-362 (duplicate of RIC-149) is already implemented by HCL.

Nokia: (1) stats related: RIC-422 posytponed to early Dawn. Related stats-items (RIC-33, RIC-126) postponed to later (likelly ZZZ_future). (2) submgr related RIC-76 and RIC-71 were postponed.

ATT: (e-mail sent): RIC-359 (likely postponed)

Status 2020-11-05: Remaining open items

RIC-56: I now moved all sub user storied for actual alarms as separate independent Epics. Can be tested with artiifical alarm or QP driver xApp alarm. The framework is ready. Marking RIC-56 as Done.

RIC-57: two subitems open (for Nune 2020-11-12 reminder sent) and one for Timo (RIC-104). Two e-mails sent. Result: RIC-104 (not yet done, move out of Cherry) Done

RIC-76:  e-mail sent as item 6 in bulk mail.

RIC-95: Completed (2020-11-12)

RIC-359: Queried status. 2020-11-12: Reminder sent

RIC-360, RIC-150. RIC-362, RIC-509: Reminder to subteam h1 sent.

RIC-363: e-mail send to Matti. 2020-11-12: reminder sent and Matti will close it with some conclusions. DONE

RIC-365 DONE. and remaining subuser stories (like RIC.429) moved to future work epic (RIC-681)

RIC-367 DONE and two subitems moved to Dawn RIC-682. xapp-framework python. e-mail sent we need to get the E2AP work done, and then we could extract one subitem as own epic and clsoe teh oevrall item.

RIC-422: e-mail send to Nune (bulk mail)

Status 2020-09-30: (a) I (PTL) am happy to see HCL doing work on Sonarqube for repos. Much more work done by HCL in context of benchmarking (simulator work), new helm and k8s version, Redis cluster suppor and testing, JIRA link for team H1  (b)  Samsung also doing key work items, e.g. for RIC-95 health check (with side affect of support for E2 SERVICE QUERY and related) - suffering from simulator support (RIC-372 already mentioned below), work started on demo (aka more elboarte hello world) xApp in go/python. (c) four items moved out of Cherry as already visible that not enough time: link . (d) 28 Cherry items = 4 moved out of Cherry + 10 done + 14 in progress or still to be started (e) Matti and Thoralf gave a presentation on RIC status in the virtual ONeS 2020 (link). Waiting for copyright/licensing results between O-RAN and O-RAN SC.

Status 2020-09-02: (a) I (PTL) am happy to see teams from Samsung and HCL joining the project with them actively working on capabilities related to the E2 simulator (actually in Alex' simulator project), more test automation (using the robotframework), benchmarking, SDL (shared data layer). (b) RIC-372 was the first commit from these new participants (c) we might be aiming for self-certification under LF's CII badge level "basic", (d) work on O1-related functions, like E2 and A1 statistics, or some alarms already done. (e) Adaptation to E2APv1.1 (likely released in November) only happening post-Cherry.

Non-Real-time RIC (A1 Interface) (NONRTRIC)

Primary Goals:
  • The primary goal of Non-RT RIC is to support intelligent RAN optimization by providing policy-based guidance, ML model management and enrichment information to the near-RT RIC function so that the RAN can optimize, e.g., RRM under certain conditions.
  • It can also perform intelligent radio resource management function in non-real-time interval (i.e., greater than 1 second).
  • Non-RT RIC can use data analytics and AI/ML training/inference to determine the RAN optimization actions for which it can leverage SMO services such as data collection and provisioning services of the O-RAN nodes.
  • Non-RT-RIC will define and coordinate rApps (Non-RT-RIC / SMO appliciations) to perform Non-RT-RIC tasks.
  • Non-RT-RIC will also host the new R1 interface (between rApps and SMO services)

Cherry Feature Scope:

  • A1 Policies:
    • A1 Policy Management Service (hosted in ONAP CCSDK)
    • A1 Policy Controller Adapter (hosted in ONAP CCSDK)
    • A1 Simulator / test stub (SIM project)
    • A1 Policy Control-Panel (PORTAL project)
    • Support A1-AP v2.0.
  • A1 Enrichment Information
    • Initial version of A1 EI Job coordination function/service
  • Deployment/Integration
    • Docker-based & OSC Kubernetes deployment & ONAP OOM Kubernetes deployment (Overlaps with SMO project)
  • rApps
    • Very simple hello-world rApp
    • TrafficSteering usecase
    • Healthcheck usecase
  • rApp support
    • Initial rApp catalogue/inventory
    • Initial approach with rApp packaging (overlaps with "common App" usecase, & SMO project)
  • Requirement gathering & initial test/integration with ML supporting functions in NONRTRIC/SMO
  • Requirement gathering & initial test/integration with data collection & coordination functions in NONRTRIC/SMO
  • Requirement gathering & initial test/integration with CMDB (if progressed in ONAP), Topology & Inventory functions in SMO

Update - 06/October/2020

  • Prototyping of the A1 enrichment Information coordination service is in progress.
  • Initial prototype of rApp registration / catalogue function, Very simple hello-world rApp.
  • Ongoing work to support O-RAN WG2 A1-P spec.
  • A1 Policy Management Service and A1 Policy Controller Adapter hosted in ONAP CCSDK are getting ready for ONAP Guilin Milestone RC0.
  • Other ongoing tasks: documentation, automated integration testing, CSIT, Run benchmark test in a cloud instance, Function Test environment refactoring, etc.

Update - 04/November/2020

  • Initial rApp catalogue is mostly ready for first tests.
  • A1 Enrichment Information job coordination function ready.
  • Ongoing work on A1 EI job control in NONRTRIC Control Panel.
  • A1-AP v2.0 (A1 Policy) is ready for implementation (Internal implementation already completed, now ready for release to the community)
  • Integration of ONAP A1 Controller functions
  • Extensions & evolution for NONRTRIC Control Panel & A1 SIM (version update, & gneral improvements)
  • A1 Policy Management Bench-marking completed ... more info to follow
  • Other ongoing tasks: documentation, automated integration testing, CSIT, Function Test environment refactoring, etc.

Update - 08/December/2020

  • A1 Enrichment Information (EI) Coordination function ready for release
  • Updated A1 EI job control in NONRTRIC Control Panel ready for release
  • Updated A1 EI simulator integrated in A1 SIM
  • Initial rApp catalog ready for release
  • A1-AP v2.0 (A1 Policy) functionality in A1 Adapter, A1 Policy Management System, NONRTRIC Control Panel, and A1 SIM
  • ONAP A1 Controller functions integrated
  • General extensions & evolution for NONRTRIC functions (version update, & gneral improvements)
  • HTTP Proxy support added for A1 Interface (Policy)
  • Other ongoing project maintenance tasks: documentation, automated integration testing, Function Test environment refactoring, etc.
  • Demo available at: 2020-12-04 - OSC NONRTRIC Cherry Demo

PTL: John Keeney

Jira: Count of Epics ( 20 issues ), User Stories, Tasks, and Issues:  455 issues

OAM (O1 Interface)

Primary Goals:

update OAM projects for latest O-RAN Specifications
  • O-RAN Operations and Maintenance Architecture Version 3.0 - April 2020

  • O-RAN Operations and Maintenance Interface Version 3.0 - April 2020

  • O-RAN Use Cases Detailed Specification 2.0 - April 2020

    • O-RAN Management Plane Specification Version 3.0 and YANG Models Version 3.0 - April 2020
    Draft O1 yang models implemented and tested against the SIM implementation - not published in LNF repos
  • support of the application LCM use case
    • Discussion about the details together with the SMO project
  • handover SMO artifacts to new SMO project

    • Update to newer O-RAN specs (E2,A1,O2,O1) and related features.

    Original primary goals: Update to E2APv1.1 (E2 Node configuration transfer in E2 Setup and E2 Configuration Update (even if likely changing again in E2APv2.0) and E2SM OID support in internal E2SM function query interfaces) // support for A1-EI (as per A1APv3.0) // support for O2 as per WG6 use cases // support for RIC-708 O1-CM to xApps // RIC-734 Include time series database into RIC platform (InfluxDB) for usage by xApps // RIC-421 O1 mediator graceful restart with O1 data being persisted over restarts // Concrete alarms from RIC platform (related to message overload): RIC-204, RIC-203 // SDK package, well documented interfaces to be used by xApps via xApp frameworks // Portability SDK (in xApp project) // REST interface for subscription management. 35 Epics planned: link and 11 items as stretch goals: link

    Achieved D release highlights = high-level release notes (2021-06-28) below (note that the release image list is here: Near-RT RIC (D release))

    • Some of the features are demoed here: 2021-06-08 Dawn. An extract of more fine-grained per component releases notes can be found in the attachement of [this page].
    • REST interface for xApps towards E2 subscription manager. No need to encode E2AP subscription messages in the xApps anymore. The Xapp framework for Go already supports/uses this.
    • Support for A1-EI (Enhancement information) to xApps. The A1 container now uses Ubuntu base image (like all others) and not Alpine anymore.
    • SDL: multiple groups of SDL standalone or sentinel instances.
    • SDL-py: Pack all the events in a channel to one DB notification to be in line with SDL Golang
    • A lot of extra load/scalability testing (using a new bouncer xApp) and functionality testing (E2, ...) was done under RIC-150 using a "bouncer xApp".
    • Wider scope of the xapp framework for python related to SDL, xapp registration, RNIB and E2AP handling.
    • We added InfluxDB as optional platform service time series database (RIC-734)
    • Support for O2 as per WG6 use case "Deploy xAPP in Near-RT RIC" in O-RAN Orchestration Use Cases v2.0. This also includes a change in how xApps register as part of their startup.
    • libe2ap (asn1c-based) can be re-used by components to encode/decode E2AP ASN.1 PDUs (Protocol Data Unit)
    • E2 statistics are now visible as VES metrics events
    • RMR raises alarms using the RIC alarm system in temporary overload situations
    • The Near-RT RIC can be deployed on Kubernetes 1.18 and helm 3. For the first time, this and all robot framework based "end-to-end" tests have also been verified in the O-RAN SC lab.
    • The Near-RT RIC project now achieved the CII (Core Infrastructure Initiative) badge "passing": (link).

    For the D release of the near-RT RIC we did only limited integration testing: only the use case: deploy RIC, deploy xApp and make E2 connection were tested.

    PTL: Thoralf Czichy

    Status 2021-07-05: Work is completed for the following 25 (19 epics and 6 "others") items link. All of these are already "done". The following 24 items (17 epics and 7 "others") we had to move out from Dawn content link. None of the stretch goals (link) has been worked on. See release highlights (above) for what has been achieved. Most notable items that were dropped are support for the E2APv1.1 capabilities "config transfer" and "OID support (i.e., we continue with E2APv1.0), RIC-708 O1-CM to xApps. Discussion on the portability SDK is still work in progress. We continue to support all the existing SDKs via the xapp Frameworks for C++, python and go.

    Status 2021-03-03: Work started on many items. 31 Epics planned: link and 15 items as stretch goals: link. Start of release snapshot (MS Excel): link For CII compliance (link)we now do some checks every two weeks in the status meeting and have started a Release criteria checklist template that we go through before releasing, Note that we update to E2APv1.1

    D release source code, container images and deployment instructions

    Each repository has a branch named "dawn" that can be accessed using git: "git clone --branch dawn "https://gerrit.o-ran-sc.org/r/ric-plt/e2". Make sure to replace the URL with correct repositories. Note that this branch is in maintenance and all new development is done in branch "master". The complete list of repositories belonging to  the RIC platform is defined here: Scope of the near-RT RIC platform and its components (summary).

    In order to deploy the D release of the near-RT RIC platform you can re-use the pre-created container images as defined here. The same instructions as always apply, i.e., follow the general latest instructions: https://docs.o-ran-sc.org/projects/o-ran-sc-ric-plt-ric-dep/en/latest/ → Installing Near Realtime RIC in RIC Cluster, but make sure to use "git clone --branch dawn ..." instead of "git clone ..." when cloning it/dep and ric-plt/ric-dep.


    Non-Real-time RIC (A1 Interface) (NONRTRIC)

    Primary Goals:
    • The primary goal of Non-RT RIC is to support intelligent RAN optimization by providing policy-based guidance, ML model management and enrichment information to the near-RT RIC function so that the RAN can optimize, e.g., RRM under certain conditions.
    • It can also perform intelligent radio resource management function in non-real-time interval (i.e., greater than 1 second).
    • Non-RT RIC can use data analytics and AI/ML training/inference to determine the RAN optimization actions for which it can leverage SMO services such as data collection and provisioning services of the O-RAN nodes.
    • Non-RT-RIC will define and coordinate rApps (Non-RT-RIC applications) to perform Non-RT-RIC tasks.
    • Non-RT-RIC will also host the new R1 interface (between rApps and SMO/NONRTRIC services)

    D Feature Scope:

    • NONRTRIC Functions: (NONRTRIC Release D Wiki)
      • Integrated A1 Adapter from ONAP (controller – mediation)
      • Integrated A1 Policy Management Service from ONAP (controller – A1 policies)
      • OSC A1 Enrichment Information Coordinator (controller – A1 EI Job management)
      • OSC Non-RT-RIC Control Panel (GUI – for A1-P & A1-EI Job management)
      • OSC A1 Simulator (a stateful test stub to simulate near-RT-RIC end of A1 interface – A1-P & A1-EI)
      • OSC (initial) APP catalog (for registering/querying APPs)
      • Initial K8S Helm Chart LCM Manager - for APP µServices etc. (ONAP & OSC) (new)
      • Initial Service Exposure Function (new)
    • In D Release: (NONRTRIC Release D Wiki)
      • Improved A1-PMS NBI (REST & DMaaP) (Rest style alignment)
      • Runtime configuration API (REST) for A1 Policy Management Service (e.g. add/remove adapters, near-rt-rics, security certs, etc)
      • Deployment – Continued improvements for Docker & Kubernetes
      • Extended/Easier deployment options with OSC IT/DEP project (SMO/NONRTRIC deployment)
      • Improving CI/CD to support include A1 Policy controller dependencies from ONAP
      • Multi-version support ( O-RAN A1-AP v1.1, v2.0, v2.1,v3.0 & OSC pre-spec A1)
      • Improved status monitoring/notification of A1-EI Jobs
      • Further improvement in security cert management (All interfaces can now be secured using TLS)
      • Re-architect & improve usability of Non-RT-RIC Control Panel (GUI)
      • Extend NONRTRIC Control Panel to edit/create A1 Enrichment Types/Jobs
      • Extend NONRTRIC Control Panel to configure A1 Policy Management Service
      • Configurable Service Exposure function – Extends/Replaces static exposure gateway in OSC Cherry
      • K8S Helm Chart LCM function for App µServices
      • Update NONRTRIC demo/test environment (one-click tests/use-cases, docker & single/multi-node K8s env)
      • OSC e2e integration use case – O-RU-FH-HelloWorld recovery
        • App to instigate O-RU-FH connection recovery after failure – via O-DU
          • Multiple implementation options – standalone µService and/or deployable ONAP-PF policy script
      • CII badging – Already achieved Bronze/Passing Grade
    More detail:

    PTL: 

    Jira:

    D release source code, container images and deployment instructions


    Operation and Maintenance (OAM)

    Primary Goals:

    • updates of OAM related interface definitions based on
      • YANG from WG4 - O-RAN Management Plane Specification - YANG Models 5.0 - November 2020 (with dependencies to IETF data models)
        • status: done
      • YANG from WG5 - O-RAN O1 Interface for O-DU 1.0 - YANG Models - November 2020 (with dependencies to 3GPP data models) 
        • status: after feedback of WG5, related merge request was abandoned - instead a pipline will be establish with O-RAN bitbuckets.  
      • YANG from WG1 - O1-interface (November 2020 train)
        • status: not approved by O-RAN
      • VES from ONAP DCAE - VES 7.2
        • status: done
      • Notification syntax from 3GPP TS 28.532 V16.6.0
    • support D-Release use case "O-RU recovery"
      • see Feature Scope below
    • handover SMO artifacts to new SMO project

    D Feature Scope: 

    • Update to OpenDaylight Silicon
    • Support of Callhome via TLS
    • CallHome to VES:pnfRegistration 
    • o-ran-fm.yang/alarm-notif to VES:fault

    PTL: Martin Skorupski

    D release source code, container images and deployment instructions (and status)

    Jira: Count of Epics ( 15 issues ), User Stories, Tasks, and Issues:  166 issues

    Source Code:

    Integration:

    Release notes:

    Please see:  Use Case Flow tests for D-Release


    O-RAN Central Unit (OCU)

    Primary Goals: 
    • In the absence of O-CU, Radisys commercial CU image to be used for E2E testing

    D Release Feature Scope: 

    • Radisys Commercial CU being used as a test fixture for E2E testing
    PTL:

    Status:

    Radisys Commercial CU being used as a test fixture.

    H/W and S/W requirements have been shared and awaiting the same to be configured.

    D release source code, container images and deployment instructions

    not applicable


    Cherry Feature Scope: 

    • Switch to Java11
    • Switch to OpenDaylight version Sodium (O1 termination NetConf)
    • https only support for  VES-Collector (O1 termination VES)
    • full IPv6 support

    Please see OAM Cherry page for further details

    PTL: Martin Skorupski

    Status:

    Jira: Count of Epics ( 15 issues ), User Stories, Tasks, and Issues:  166 issues

    Demo of OAM use cases

    O-RAN Central Unit (OCU)

    Primary Goals: 
    • Source code includes RRC, Ng, E1, F1. Platform and OM are provided in  dependent libraries.
    • O-CU-CP is integrated with O-CU-UP, O-CU functions should be complete.

    Cherry Feature Scope: 

    RRC: 

    • support Broadcast of system information；
    • support RRC connection control；

    NG:

    • support PDU Session Management Procedures
    • support UE Context Management Procedures
    • support Transport of NAS Messages Procedures
    • support Interface Management Procedures

    E1:

    • support Interface Management procedures
    • support Bearer Context Management procedures

    F1:

    • support Interface Management procedures
    • support UE Context Management procedures
    • support RRC Message Transfer procedures
    • support System Information Procedures
    PTL: Yingying Wang

    Jira: Count of Epics, User Stories, Tasks, and Issues:

    Image RemovedOCU-1 - O-CU F1 interface for Release B TO DO   F1

    Image RemovedOCU-2 - O-CU SDAP TO DO  SDAP

    Image RemovedOCU-3 - O-CU PDCP TO DO  PDCP

    Image RemovedOCU-4 - O-CU RRC TO DO  RRC

    Image RemovedOCU-5 - O-CU Ng TO DO  Ng

    Image RemovedOCU-6 - O-CU E1 TO DO  E1

    O-DU High

    Primary Goals: 

    • Develop L2 layers to achieve UE attach with UL and DL data on FDD, mu=0, BW=20 MHz
    • Interface with O-CU on F1AP
    • Interface with near RT RIC on E2AP
    • Interface with O-DU Low using FAPI
    • Interface with OAM on O1

    Cherry Feature Scope: 

    • Implement UE attach procedure with basic scheduling on FDD, mu=0, BW=20 MHz
    • Implement single UE DL and UL data path and bench-marking
    • Add support for 64QAM modulation scheme in DL and 16QAM in UL
    • Add support for all short PRACH formats
    • Integrate O-DU High with O-DU Low
    • Integrate with Viavi sim/O-CU
    • Explore O1 interface
    • Establish Netconf session for O1 interface for CM
    • Support Health Check use-case

    Updated: 16 December 2020

    Documentation and release related activities for Cherry release have been completed.

    Jira: EPICS Status below:

  • https://jira.o-ran-sc.org/browse/ODUHIGH-10 - Done
    • As an O-DU L2 developer, I want to implement UE attach procedure with basic scheduling
  • https://jira.o-ran-sc.org/browse/ODUHIGH-188 - Done
    • As an O-DU L2 developer, I want to add support for all short PRACH formats

  • https://jira.o-ran-sc.org/browse/ODUHIGH-191 - Done

    • As an O-DU L2 developer, I want to explore O1 interface
      • Made certain exploration and begun work on CM and health check use-case
  • https://jira.o-ran-sc.org/browse/ODUHIGH-196 - WIP
    • As an O-DU L2 developer, I want to Establish Netconf session for O1 interface for CM
      • CM  supported limited to IP and port configs for F1 and E2 interface using custom yang files
      • Code yet to be merged

    • O-DU High

    Primary Goals: 

    • O-DU high integration in Radio mode
    • Initial access and Attach procedure testing in Radio mode
    • DL and UL data path in FDD, 20 MHZ with 256 QAM and 64 QAM respectively
    • Static TDD mode support with Numerology =1
    • O1 enhancement
    • Closed Loop Automation Use case support

    D Feature Scope: 

    . 1. Achieve UL and DL data flow using FDD mode on 20 MHz Bandwidth, Numerology = 0

     2.Support for static TDD mode with pattern “DDDDDDDSUU” on 100 MHz Bandwidth, Numerology = 1

    • Evolve scheduler to support UL and DL scheduling of signaling and data messages on single spectrum in TDD mode
    • Expand scheduler to support Frame structure according to numerology = 1
    • Updates to cell broadcast for TDD and numerology = 1

    3.Development activity for Closed Loop Automation use-case

    • Support for cell stop and restart within O-DU High layers
    • Support for cell stop and restart towards O-DU Low
    • F1AP Enhancements towards O-CU indicating cell stop and restart

    4.Integration

    • Integration with O-DU Low in Radio mode
    • Integration with CU

    5.End to end testing support (O-RU<->O-DU-LOW<->O-DU-HIGH<->RSYS CU<->Viavi 5G Core )

    6.O1 enhancements - by HCL

    • Re-structure O1 module to run as a thread in ODU-High
    • CM Support - IP and Port configuration for DU, CU stub and RIC stub via Netconf interface
    • Support for Closed Loop Automation use-case

    PTL: Sachin Srivastava

    Status:

    Updated:  7th July 2021

    JIRA: Epics Status below:

    • https://jira.o-ran-sc.org/browse/ODUHIGH-184 - Done
      • As an O-DU L2 developer, I want to implement single UE DL data path and bench-marking
    • https://jira.o-ran-sc.org/browse/ODUHIGH-185 - Done
      • As an O-DU L2 developer, I want to implement single UE UL data path and bench-marking
    • https://jira.o-ran-sc.org/browse/ODUHIGH-186 - Done
      • As an O-DU L2 developer, I want to add support for 64QAM modulation scheme in DL
        • Basic code changes complete. Testing in progress for data path
    • https://jira.o-ran-sc.org/browse/ODUHIGH-187 - Done
      • As an O-DU L2 developer, I want to add support for 16QAM modulation scheme in UL
        • Basic code changes complete. Testing to be done for data path
    • https://jira.o-ran-sc.org/browse/ODUHIGH-264 - Done
      • As an O-DU L2 developer, I want to add support for Mu1
        • Code changes at DU APP completed.
        • Resource allocation for SSB to msg5 completed
        • Code changes for UE registration flow in progress
        • Updates to k0, k1, k2 in progress
    • https://jira.o-ran-sc.org/browse/ODUHIGH-265 - Done
      • As an O-DU L2 developer, I want to add support for 100 MHz Bandwidth
        • Code changes at DU APP completed.
        • Resource allocation for SSB to msg5 completed
        • Code changes for UE registration flow in progress
        • Updates to k0, k1, k2 in progress will be continued in E release
    • https://jira.o-ran-sc.org/browse/ODUHIGH-266 - Done
      • As an O-DU L2 developer, I want to add support for TDD mode
        • Code changes at DU APP completed.
        • Resource allocation for SSB to msg5 completed
        • Code changes for UE registration flow in progress
        • Updates to k0, k1, k2 in progress will be continued in E release (Irrespective of FDD or TDD stack)
    • https://jira.o-ran-sc.org/browse/ODUHIGH-299 - Done
      • As an O-DU L2 developer, I want to develop O-DU High Layers to support Closed Loop Automation Use-case
        • Yang modules to be supported by O-DU to ensure the end-to-end functionality of the use case "Closed loop" is in progress. Basic configuration is agreed to support CLA use case.
        • Internal call flow/message sequence between O-CU and O-DU for cell activation and deactivation is clarified. Call flow updated at 

          https://wiki.o-ran-sc.org/display/RSAC/Closed+Loop+Automation+Call+Flow+-+O-DU+High+APIs.

        • UE delete functionality complete
        • Cell delete functionality complete
        • Issue with mis-coordination between cell delete and DL RRC message, resolved.
        • Code changes for CU Interaction is completed
        • Code changes for Config update over F1 interface is completed
        • O1 Integration for O-DU  for CLA is completed ( Cell stop and Cell restart)
        • Blocker : code segmentation is observed, analysis is going on (code optimization is required to be scoped in E release)
    • https://jira.o-ran-sc.org/browse/ODUHIGH-267 - Done
      • As an O-DU L2 developer, I want to integrate O-DU High with O-DU Low in Radio Mode
        • SSB transmission successful
        • Debugging issue with Sib1 transmission , PDCCH is received but no PDSCH seen at O-DU low.
        • PDSCH for SIB1 is detected at L1 but L1 does not process it. Pointer is to check the PDSCH PDU parameters
        • Further debug sessions needed to close the ongoing issues.
        • There is no breakthrough even after several debug sessions with O-DU Low
        • SIB1 detection at L1 is successful. PHY.XML is updated with removing the hardware accelerator (<dpdkBasebandFecMode> from 1 to 0 to force the SW encoder)
        • For the CLA usecase, Cell stop request is received from O-DU high to low but O-DU low sends stop indication multiple times. This issue is fixed in L1 later binary 20.08. This binary update will happen in D-maintenance phase. 
    214
    • get-alarm list to be supported i.e., Health Status Retrieval
    • Code merged into master branch.
    • 268 - Done
      • As an O-DU L2 developer, I want to
    support Health Check use-case
      • integrate O-DU High with O-CU
        • Using Radisys commercial CU as a test fixture
        • New VM configured as per H/W and S/W requirements of Radisys CU
        • The Network interfaces and CentOS version needs to be revisited for the CU machine. This is achieved with limited OSC lab setup.
    189
    • 269 - Done
      • As an O-DU L2 developer, I want
    to integrate O-DU High with O-DU Low 
    • O-DU High successfully integrated with O-DU Low in timer mode
    • O-DU High  completed aligning with latest FAPI files from Intel for Radio mode
    • Radio mode testing to be begin once O-RU integration is complete
  • https://jira.o-ran-sc.org/browse/ODUHIGH-184 - WIP
    • As an O-DU L2 developer, I want to implement single UE DL data path and bench-marking
      • Design in progress.
      • to support End to End testing scenarios
        • Testing of broadcast messages at O-RU emulator set to begin
        • Viavi confirmed receiving at O-RU. Needs verification from UE sim.
        • Debug session is planned on 23rd June to achieve SSB and SIB1 transmission till UE simulator and then follow with RACH procedure.
        • Latest issue: the eCPRI packets differentiation between control plane and user plane through vlan id is supported by Intel, however O-RU support the packet differentiation based on eCPRI packet type. hence the fronthaul transmission validation is blocked.
        • Intel shall update the L1 package supporting C/U plane differentiation using eCPRI packet type in the D-release maintenance phase.

    Updates from HCL:

    185
    WIP
    • Done
      • As an O-DU L2 developer, I want to
    implement single UE UL data path and bench-marking
    • Design in progress
    • PUCCH code changes in progress
    186
    WIP
    • Done
      • As an O-DU L2 developer, I want to
    add support for 64QAM modulation scheme in DLCode under review for signaling
    187
    TODO
    • Code under review for signaling
    • Done
      • As an O-DU L2 developer, I want to
    add support for 16QAM modulation scheme in UL
      • develop O-DU High Layers to support Closed Loop Automation Use-case
    190
    WIP
    • Done
      • As an O-DU L2 developer, I want to
    integrate
      • develop O-DU High Layers to support Closed Loop Automation Use-case
    • https://jira.o-ran-sc.org/browse/ODUHIGH-328 - Done
      • As an O-DU L2 developer, I want to develop O-DU High Layers to support Closed Loop Automation Use-case
    •   https://jira.o-ran-sc.org/browse/ODUHIGH-347 - Done
      • As an O-DU L2 developer, I want to develop O-DU High Layers to support Closed Loop Automation Use-case
        • Tested locally with SMO both with IPv4 and IPv6. Able to mount and connect ODU.
        • Integration with SMO in working fine with IPv4 but with IPv6 could not tested as it is not enabled in OSC lab
        • Integration with O-DU code for cell down and up scenario is completed, validation is completed
        • Edit-config testing from SMO to ODU for cell down/up is in completed in OSC lab
    • https://jira.o-ran-sc.org/browse/ODUHIGH-349 - Done
      • As an O-DU L2 developer, I want to develop O-DU High Layers to support Closed Loop Automation Use-case

    Dependency/Blockers:

    • O1 configuration for day-1 shall need to be completed to start with CLA. However basic configuration e.g. cell state/operational state/admin state shall be supported initially. Use admin state as unlocked to validate the RU link failure.
    • Server(VM) configuration (H/W and S/W) to mount Radisys CU as a test fixture. 
    • Unable to use valgrind with Intel libraries. Debugging must be carried out with Alternate methods.
    • Intel/Viavi to confirm successful decoding of SSB/SIB1 at UE sim (TM500).


    D release source code, container images and deployment instructions

    Release-Notes — o-du-l2 master documentation (o-ran-sc.org)


    O-DU Low

    Primary Goals:  

    —Continue O-DU low and O-DU high pairwise test.

    —FAPI P7 massage integration -> Ongoing

    —Continue

    with Viavi softwares
    • integration plan discussion begun.

    Dependency/Blockers:

    • Custom Yang files will be used for Dev activity.
    • FAPI files being used provided by INTEL, which is not completely in-line with the latest released version from SCF.

    O-DU Low

    Primary Goals:  

    • Integrate with O-DU High with FAPI interface with cherry release aligned IOT profile
    • Integrate with O-DU emulator from Viavi with cherry release aligned IOT profile
    • Support E2E integration with O-CU, O-DU High, O-RU emulator and UE for UE attachment

    Cherry Release Feature Scope: 

    • O-DU Low and O-DU High integration according to RSAC and INT project alignment features and scope
    • O-DU Low and O-RU/RRU emulator integration  according to RSAC and INT project alignment features and scope
    • E2E integration  according to RSAC and INT project alignment features and scope
    • O-DU Low integrated with thirty party commercial SW to verify the UE attachment and traffic, update the O-DU Low version accordingly
    PTL: @Zhimin Yuan

  • Status

    • O-DU Low integrated with thirty party commercial SW to verify the UE attachment and traffic, update the O-DU Low version accordingly – Done

    Image RemovedODULOW-14 - O-DU Low integrated with thirty party commercial SW to verify the UE attachment and traffic, update the O-DU Low version accordingly DONE

  • successfully do the UE attachment and traffic

    Image RemovedODULOW-11 - O-DU Low and O-DU High integration according to RSAC and INT project alignment features and scope IN PROGRESS

    • O-DU Low and O-DU High integration – in progress

      • OSC Lab environment is installing OSC INF, O-DU Low can build/run in OSC INF
      • O-DU Low and O-DU High P5 massage integration using O-CU stub and O-DU low time mode – done
      • O-DU Low and O-DU High further P7 integration  - not start
    Image RemovedODULOW-12 - 

    O-DU Low and O-RU

    /RRU emulator integration IN PROGRESS

  • O-DU Low and O-RU/RRU emulator integration - in progress

    • according to RSAC and INT project alignment features and scope  – Done
    • integration the S-plane, O-DU low and O-RU emulator get synchronized – in progress
    • C-plane test, O-RU emulator can parse the C-plane message correctly – not start
    • U-plane test, pass SSB, PDSCH, PUSCH, PRACH channel data exchange – not start

    Image RemovedODULOW-13 - E2E integration according to RSAC and INT project alignment features and scope TO DO

  • E2E integration  – not start

      • support E2E integration with O-DU High, O-CU, O-RU emulator and UE
      • align with RSAC and INT project alignment features and scope

    emulator test.

    —Further CU plane testing -> Ongoing

    —Continue E2E test with UE simulator.

    —Support the UE attachment test

    —Development activity for Closed Loop Automation use-case

    —Support and test for cell stop and restart within O-DU High layers


    D Release Feature Scope: 

    PTL: @Zhimin Yuan

    • Status

    D release source code, container images and deployment instructions

    TODO


    Simulators (SIM)

    Primary Goals:

    • Support rapid prototyping by providing simulated interfaces

    D Feature Scope:

    • Enable "Closed Loop Use Case" demonstration by providing O1 interface Simulators for:
      • O-DU (containing o-du-hello-world YANG model)
      • O-RU (containing O-RAN-RU-FH November 2020 train YANG models)
    • O1 Simulator improvements:
      • "Blank" simulator, which allows dynamically loading any YANG models of interest, for simulating a NETCONF/YANG interface 

    PTL: Alex Stancu

    Jira: Count of Epics, User Stories, Tasks, and Issues:  5 issues

    Status:

    • O-DU O1 Simulator docker image available in Nexus (version 1.3.3) 
    • O-RU O1 Simulator docker image available in Nexus (version 1.3.3)
    • Blank O1 Simulator docker image available in Nexus (version 1.3.3)

    D release source code, container images and deployment instructions

    Docker container images are described here.

    Each repository has a branch named "dawn" that can be accessed using git: "git clone --branch dawn "https://gerrit.o-ran-sc.org/r/sim/o1-interface". Make sure to replace the URL with correct repositories. Note that this branch is in maintenance and all new development is done in branch "master". The complete list of repositories belonging to the SIM project is here.

    Deployment instructions here.

    Please see:  Use Case Flow tests for D-Release

    Simulators (SIM)

    Primary Goals:

    • Support rapid prototyping by providing simulated interfaces

    Cherry Feature Scope:

    • O1 Simulator enhancements
      • Upgrade NETCONF Server framework
    • E2 Simulator enhancements
      • Implement more message types
      • Assess if E2 Simulator can be used for benchmarking
    • Maintain alignment with latest YANG models

    PTL: Alex Stancu

    Jira: Count of Epics, User Stories, Tasks, and Issues:  5 issues

    Status (07 Oct. 2020): 

  • E2 Simulator - support for new E2 Messages - done
  • E2 Simulator - benchmarking of RIC - in progress
  • O1 Simulator - upgrade of NETCONF Server - in progress
    • OTF integration - TBD


    Infrastructure (INF)

    Primary Goals: 

    • 2 servers. 2 AIO servers with HA (high availability), the controller functionality and storage functionality will be deployed at the 2 servers with standby-active mode managed by "service management". If one server or one service in one server has error, it will be switched from active to standby one to maintain the service availability.
    • 2 AIO servers with additional worker node.

    • Implement the O-Cloud reference design, provide the real time performance to allow the O-DU and other components running on top of it.
    • Provide interaction capabilities with other components.

    D release Feature Scope:  

    • Enabe the 2 AIO severs with additional worker nodes deployment scenario
    • Major components upgrade
    • Implement the O2 interface as the MVP (will defer to next release)

    PTL: Jackie Huang

    Jira: Count of Epics, User Stories, Tasks, and Issues:

    Update at   

    • Jira
      serverORAN Jira
      columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId5ec52304-b77c-3ce7-af6a-112cb13e6008
      keyINF-172
    • Jira
      serverORAN Jira
      serverId5ec52304-b77c-3ce7-af6a-112cb13e6008
      keyINF-214

    Test:

    Release Note:

    D release source code, container images and deployment instructions

    Cherry Feature Scope:  TODO

    PTL: Xiaohua Zhang

    Jira: Count of Epics, User Stories, Tasks, and Issues:

  •  The INF project status update at INF project status for 26-Aug-2020.
  •  The INF project status update at 24-Sept-2020: 
    • The first major goal of "enable the duplex deployment with HA features" has been done. No block issue in JIRA although there are some issues left.
  • Status update 28-Oct-2020
    • The AIO deployment scenario has been supported. Althought there are some issues/bugs, but it won't affect the functionalities at all.
    • For the AIO with additional worker nodes, the codes had been checked into the repo, the verification and test is still ongoing. (it will be delayed to Dawn release).
    • Continue to support the integration test.
    • Continue to prepare the document of Cherry release.
  • Status update 11-Nov-2020
    • Already add the packages which were missing during the ODU-High/Low integration.
    • Some other issues will be addressed before 14-Nov-2020
    • In general, ready to cut-off by 14-Nov-2020
    • Status update 09-Dec-2020
  • Final image has been generated.
  • Finish the integrate test with O-DU Low/High
    • Document has been updated into repo for release note and others.



    Integration and Test (INT)

    Primary Goals: To support OSC project CI pipeline. To test and validate the components and use cases

    Cherry Feature Scope: 

    • Automated CLM and SonarQube Scanning CI Jobs
    • Improve CI
    for OSC projects
  • Validate and and Test platform and use cases 
    • PTL:  Zhe Huang
    • for OSC projects
    • Validate and and Test platform and use cases 


    PTL:  Zhe Huang

    Jira: Count of Epics, User Stories, Tasks, and Issues: 54 issues


    D release source code, container images and deployment instructions

    not applicable


    Documentation (DOC)

    Primary Goals: TODO
    Bronze Feature Scope: TODO

    PTL: weichen ni

    Jira: Count of Epics, User Stories, Tasks, and Issues:

     54 issues

    Status (28 Oct. 2020): 

    • CLM scanning jobs:
      • done: A1 and python xApp-framework
      • Pending: Rest of the projects
    • SonarQube scanning jobs:
      • 21 projects passed
      • 7 project failed
    • OSC Lab internal CI pipeline:
      • Initiate works with O-DU-low CI 
    • OSC Lab Testing and Validation
      • SMO Yang model tests completed.
      • VM created for TS use case validation.

    Documentation (DOC)

    Primary Goals: TODOBronze Feature Scope: TODO

    PTL: weichen ni

    Jira: Count of Epics, User Stories, Tasks, and Issues:

    Service Management and Orchestration  (SMO)

    D release source code, container images and deployment instructions

    not applicable


    Service Management and Orchestration  (SMO)

    Primary Goals: The primary goal of the SMO project is to integrate different software artifacts of existing open-source projects creating a fully functional open-source Service Management and Orchestration (SMO). 

    D Feature Scope:

    • Support for O1 interface
      • Implementation of NETCONF client in SMO
      • Reference implementation of a NETCONF server that O-RAN Network Functions, e.g. Near-RT RIC, CU, DU and RU can use. The code can be found at https://github.com/CESNET/netopeer2
      • A minimal set of YANG models that demonstrate the capability of the O1 interface while satisfying the closed-loop automation use-case.
    • Support for O1/VES interface
      • Demonstrate the capability to receive VES events, collect them in a dB, and display them in a dashboard.

    PTL: Mahesh Jethanandani 

    Status:  

    • An implementation of the O1 interface has been checked into Gerrit. Check out this repo. It has been tested on Ubuntu Linux version 20.04. Feedback is appreciated on other versions and operating systems. Note, this commit is not feature compatible with the O1 interface in other implementations. Some of those features have been identified and marked as enhancements in either this or the next release.
    • An implementation of the VES interface based on schema version 7.2.1, with backward compatibility to 7.0, has been submitted for Gerrit review, and review comments have been provided. Author has updated the commit based on the comments. Waiting on more reviews. Again, the commit is not feature compatible with VES interface in other implementations. Some of those features have been identified and will be added in this or the next release.

    Jira: Count of Epics ( 0 issues ), User Stories, Tasks, and Issues:  6 issues

    D release source code, container images and deployment instructions

    Docker image and instruction on how to install SMO O1 interface can be found here.

    Docker image for instructions on how to install SMO O1/VES interface can be found here.

    The repository has a branch named "dawn" that can be accessed using git. For the O1 interface the repository can be found at "git clone --branch dawn "https://gerrit.o-ran-sc.org/r/smo/o1mo/o1", whereas the O1/VES repository can be had by "git clone --branch dawn "https://gerrit.o-ran-sc.org/r/smo/ves"

    Primary Goals: The primary goal of the SMO project is to integrate different software artifacts of existing open-source projects creating a fully functional open-source Service Management and Orchestration (SMO). Cherry Feature Scope: SMO entered the Cherry release in the middle of third sprint of code development. As such its scope is fairly modest. They are validation of application packages, assuming that we can agree on the format of the package, on boarding of applications and storing them in a package catalog which also has to be agreed upon, and as a stretch goal, setting up an environment where YANG modules that will be used by O-RAN, whether they are from 3GPP, and O-RAN itself can be used by vendors developing RIC, CU, DU and the RU to test a MVP configuration.

    PTL: Mahesh Jethanandani 

    Status:  A proposal was made on application package format, and there was some agreement on it following the ETSI SOL 004 specification. The contributions into the SMO project currently validate that part of the agreement, and allow for Network Function, xApp and rApp vendors to validate their package using the tools developed in SMO.

    David Kinseyis driving package catalog requirements, which is LCM Step 3. But it was determined that package catalog can be implementation specific, and therefore SMO cannot validate any particular catalog. As such LCM Step 3 will be skipped.

    The second part of SMO was the setup of a framework for testing of YANG models that are going to be used by SMO and the Network Functions that constitute the O-RAN solution. Thanks Martin Skorupski, Zhe Huang , and Alex in setting up that framework in the OSC lab. 

    For a detailed workflow and end-to-end test manual of the two parts, refer to Cherry Release Test Plans for SMO.

    Jira: Count of Epics ( 0 issues ), User Stories, Tasks, and Issues:  6 issues