Versions Compared

Key

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


Info
iconfalse

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


ZOOMhttps://us02web.zoom.us/j/89069708424?pwd=aGJOZm54eTUxd0FXR0VCU1N0ejBrUT09
Meeting ID: 890 6970 8424


Attendees

Informed

Discussion items

TimeItemWhoNotes
00:00Admin

Next meetings: 

2021-09-01: Martin Skorupski

2021-09-08: John Keeney (Ericsson EST) 

2021-09-15: Martin Skorupski 

2021-09-22: John Keeney (Ericsson EST) 

00:01O-RAN-SCO-RAN-SC PTLs
00:10PM streaming

using VES for PM streaming → discussion

Attachments
previewfalse
uploadfalse
oldfalse
labelsves

  • gathering feedback
  • Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyDCAEGEN2-2880
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.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
  • ...

Suggestion

  • update LNF slides from Feb and May

Q/A






End

00:20O1-VES
  • O1-VES collection (@33:30 in recording)
    • PM Mapper - for PM Bulk 
      • Stanislav Marszalek Stanislav Marszalek Slides: 
        • View file
          name20210728 - Stanislav Marszalek - PM Mapper - output.pptx
          height150
      • O1 is just via ves:fileReady → FTPes 
      • issues in PM-Mapper should be handle via Jira ans slack
        • https://lists.onap.org/g/onap-discuss/message/23433
        • DCAEGEN2-2874 PM Mapper output - sMeasTypesList    
          Jira Legacy
          serverSystem Jira
          columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
          serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
          keyDCAEGEN2-2874
        • DCAEGEN2-2873 PM Mapper output - granularityPeriod issue   
          Jira Legacy
          serverSystem Jira
          columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
          serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
          keyDCAEGEN2-2873
      • issues in VES spec are more problematic, as O-RAN Alliance is using the domain "stndDefined"

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 Former user (Deleted)

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:

notifyMOIAttributeValueChanges

notifyMOICreation

notifyMOIDeletion

notifyMOIChanges


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 3gpp....zip (https://www.3gpp.org/ftp/Specs/archive/28_series/28.532/28532-g81.zip → 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. https://wiki.lfnetworking.org/download/attachments/56066778/LFN_June2021_ONAP_SON_Rel9_20210610_v1.pptx?version=1&modificationDate=1623339917000&api=v2

  • 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: gerrit.onap.org:29418/dcaegen2/collectors/ves
00:xx

O-RAN SC: Copying/Releasing helm charts in O-RAN-SC nexus repo

https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-22586 (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?

Sebastien Determe: adds some info

Idea: store the artifacts - instead of helm - 

Jira Legacy
serverLinux Foundation Jira
serverId786ecce4-c7f8-3725-b80d-ceab920b9b14
keyRELENG-3837

ChrisC: 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 
    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyREQ-887

Meeting? on Friday 6/25

https://lists.onap.org/g/onap-meetings/viewevent?repeatid=37969&eventid=1192141&calstart=2021-06-25


Activity

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


<Martin Skorupski needed to leave. John Keeney (Ericsson EST) 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 (https://wikilf-onap.onapatlassian.orgnet/wiki/pages/viewpage.action?pageId=10342227215480760)

--

Are the following pages related?

  • CNF/VNF deployments

2021-07-07:

way forward

2021-07-14:

2021-07-21:

2021-07-28:

  • 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 

2021-08-04:

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

2021-08-18:

  • 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

Q/A



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

<End>



END






00:00Use Case

@all

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>



Action items

  •