Skip to end of metadata
Go to start of metadata

 | 9am PDT |  noon EDT | 16:00 UTC | 18:00 CEST | 21:30 IST 

Meeting ID: 890 6970 8424



Discussion items


Next meetings: 

2021-09-01: Martin Skorupski

2021-09-08: John Keeney 

2021-09-15: Martin Skorupski 

2021-09-22: John Keeney 

00:10PM streaming

using VES for PM streaming → discussion

00:30Update for ONAP Req sub-committe

ONAP Requirements subcommittee request an update on areas where ONAP and O-RAN share interest.

  • What is/are the area/s of common interest?
  • What is the current state of affairs?
  • What are the future topics to address?
  • Any issues that require more emphasis from the community, or more formal collaboration relation between the two communities is needed?
  • Anything else you think it worthwhile to highlight.

Updates/feedback for next Monday meeting

  • SON based use case
  • Slice based use case
  • VES messages
  • A1 Policy
  • SMO Deployment
  • Test environment
  • Simulators
  • Topology
  • ...

Further discussions 

  • O2 
  • coordination O-RAN-SC / ONAP
  • primary / secondary yang model - feedback to yang developers
  • ...


  • update LNF slides from Feb and May




INFO: PM Streaming: ASN.1 via WebSocket according to O-RAN SpecO-RAN Operations and Maintenance Interface 4.0 - November 2020

Martin SkorupskiCheck with O-RAN Wg10 where the restriction to ASN.1 came from. 

Topic was discussed in DCAE Meeting: 2021-08-04 DCAE Meeting Notes

HV-VES vs "standard" VES collector

info: HV-VES not used by OOF-SON use case (yet)

info: no relation between HV-VES and PM-Mapper

2021-08-11 Krystian Kedron

I refactored current Jira’s base on our discussion:

And also create a new one:

VES - CM-Notify

The following 3GPP CM notifications specified in 3GPP TS 28.532 [4] are supported in O-RAN:





Its syntax is defined in

~/_3gpp/MnS ((SA88-Rel16))

└─ $ ▶ grep -anri notifyMOI*

OpenAPI/provMnS.yaml:87:        notifyMOICreation:

OpenAPI/provMnS.yaml:95:          $ref: '#/components/schemas/notifyMOICreation-NotifType'

OpenAPI/provMnS.yaml:108:       notifyMOIDeletion:

OpenAPI/provMnS.yaml:116:         $ref: '#/components/schemas/notifyMOIDeletion-NotifType'

OpenAPI/provMnS.yaml:129:       notifyMOIAttributeValueChange:

OpenAPI/provMnS.yaml:137:         $ref: '#/components/schemas/notifyMOIAttributeValueChange-NotifType'

OpenAPI/provMnS.yaml:150:       notifyMOIChanges:

OpenAPI/provMnS.yaml:158:         $ref: '#/components/schemas/notifyMOIChanges-NotifType'

OpenAPI/provMnS.yaml:365:        - notifyMOICreation

OpenAPI/provMnS.yaml:366:        - notifyMOIDeletion

OpenAPI/provMnS.yaml:367:        - notifyMOIAttributeValueChange

OpenAPI/provMnS.yaml:513:    notifyMOICreation-NotifType:

OpenAPI/provMnS.yaml:530:    notifyMOIDeletion-NotifType:

OpenAPI/provMnS.yaml:546:    notifyMOIAttributeValueChange-NotifType:

OpenAPI/provMnS.yaml:569:    notifyMOIChanges-NotifType:

OpenAPI/genericNrm.yaml:297:        - notifyMOICreation

OpenAPI/genericNrm.yaml:298:        - notifyMOIDeletion

OpenAPI/genericNrm.yaml:299:        - notifyMOIAttributeValueChanges

Please see further details:

Shankar: point to a ( → v16.8.1)

Marcin has looked into it. 

  • to complete and validate the entire json - additional yamls are required.
  • there are reference inside to other schemas - needs to be analyses - for validation on the ves-collector.
    • more infos next week

OOF-SON use case roadmap from last June.

Marcin was referring to slide 16 in this June 2021 LFN slide deck for the ONAP-SON use case.

  • VES message handling on SDN-R 
    • used to update CPS
    • code is in ccsdk/features - northbound (CM Notification Support in ONAP)
    • DCAE VES Collector - implementation for VES 7.2 in Honolulu  
    • TODO: add link to nexus dcae-ves-collector–image.... (???1.8.0???)
    • gerrit repo:

O-RAN SC: Copying/Releasing helm charts in O-RAN-SC nexus repo (maybe restricted access?!?!)

Status: canceled (Nexus does not support Helm chart distribution)

Question from O-RAN-SC to ONAP: What is possible in ONAP nexus?

Sébastien Determe: adds some info

Idea: store the artifacts - instead of helm -  RELENG-3837 - Getting issue details... STATUS

Christophe Closset: ONAP on the way to move for helm charts to gitlab....

00:xxSMO deployment options

SMO deployment options

  • no tested helm for OAM in O-RAN-SC D-Release - idea update the one from C-release
  • for Non-RT-RIC a new helm is available - still some updates to be done
  • Please see presentation within  REQ-887 - Getting issue details... STATUS

Meeting? on Friday 6/25


  • kubernetes updates
  • issues with certs addressed
  • reuse of O-RAN-SC helm 
  • Winriver lab

<Martin Skorupski needed to leave. John Keeney continues minutes. See also: 2021-06-23 Meeting notes - Joint OAM / NONRTRIC / SIM SCRUM meeting >

INFO from Christophe - 2021-06-30:

Just a few notes:

  • We have agreed with ONAP and other members of O-RAN SC to keep an ad-hoc call on Friday to discuss technical details for now (will remove this meeting once all details are sorted out and use the joint meeting to report status)
  • Main comment from John is that we cannot consider an SMO deployment without having a way to deploy Non-RT-RIC as well as ONAP components (hence a debate on how this should materialize : extend OOM? )
  • We have progressed on the POC in the meanwhile, Sebastien had an idea and has pushed a small repository on github to show what we are doing for now to create a unique installation for O-RAN, trying to implement the following idea:
    • Started from IT/DEP repo, containing some Helm charts for O-RAN (including Non-RT-RIC)
    • Seems an embryo of using ONAP charts to deploy SMO components but sounded like a fork of ONAP charts
    • Instead of copy pasting OOM charts, he create a git submodule referring to oom ONAP charts repo (to keep ONAP untouched)
    • Rework the O-RAN charts to map them to the OOM structure (like OOM'ized O-RAN charts)
    • Try and build (created some makefiles, inspired from ONAP) then push them to a single chart repository
    • Merged ONAP override and O-RAN override to have a single file
    • Created an Install script to deploy the charts in a single Namespace
    • … it worked more or less

We plan to show that maybe on Friday call (


Are the following pages related?

  • CNF/VNF deployments


way forward



  • from John Keeney LFN ticket required to put helm into nexus
  • control about helm from different project


  • not much additional features required for SMO deployment.
  • next step in the area of CNF deployment in combination with SMO
    • as demoed one year ago by Samsung (including closed loop and A1 Policies)
    • use case will be updated to Honolulu 


  • no updates on last weeks call
  • cnf deployment - reuse of existing use case implementation.


  • demo of by Samsung for CNF deployment - recording available on the Friday meeting wiki
  • updates on OOM for O-RU-Sim and O-DU-Sim deployment as CNF
  • work in progress


N.K. Shankaranarayanan

SON use case

  • based on O1
  • How to include A1 in the SON use case? for the Network Slicing Use Case
  • Will be discussed on Use case Realization call (on Mondays)
  • use case in O-RAN-SC regarding Network Slicing - similar but not in all details



00:00Use Case


OSC Proposed e2e integration use case: O-RU FH connection recovery

<bridge dropped recording stopped at this point. Most participants reconnected once bridge started again>

  • Topology ??: (contd)
    • John Keeney Lots of options for how this should be done properly in ONAP.
    • Swaminathan Seetharaman ONAP usecases already have some plans for this e.g. slicing, oof,  etc
    • Andy Mayer A model should be agreed in ONAP. Lots of previous discussions in ONAP - e.g. what goes in A&AI and CPS ... but that was a while ago.
    • Martin Skorupski SDNR has some topology model too - not standards based.
    • @Sven John Keeney Martin Skorupski Lots of issues with different topology models ... and most existing hierarchical models break down in a 5G/CloudRan environment
    • Lots of work ... Andy Mayer Martin Skorupski Can create a JIRA in ONAP MODCOM ...
    • ... but will keep it simple here for this use case.
  • @? Will other O1 usecases be effected? Martin Skorupski i No. O1 functions continue as before.
  • Martin Skorupski Please add feedback if any

Action items