Date

 16:00 UTC / noon EDT / 18:00 CEST
Zoom: https://zoom.us/j/619914482

Attendees

Abhinav Singh 
@Claudio 
@John Keneey
Jeff Hartley (star)
Kevin Smokowski
Konrad Bańka (star)

Herbert Eiselt
@Himesh Shukla
Lasse Kaihlavirta 

Marci Haas (star)
Marcin Sebastian Krasowski (star)
@Melanie Sater (star)
@Partik Raj 
Rajiv Vishwkarma (star)

Pawel Slowikowski (star)
Samuli Silvius 

@Ralph Stegner (star)

Tracy Van Brakle (star)
Martin Skorupski (star)


Please add yourself. Thanks!

Discussion items

TimeItemWhoNotes
00:00AdminNext meeting: 2020-07-15

O-RAN-SC

New Use case: App Life Cycle Management (LCM)

Questions


PoCTracy Van Brakle

PoC end of Sep - more enhanced first week of Dec

  • 5G/LTE-xHaul
  • OTIC  Europe, NA, Asia, India, Israel
  • Use cases
    • multi operator, multi operator - slicing related
    • multi-vendor Software Management
    • multi-vendor 3GPP aligned services
    • CAS, FHGW - see O-RAN Transport WG7 WG4 WG9
    • Spectrum Management (DEC)
    • Scale/Latency measurement on environments
    • O-CU, O-DU
      • TEF, DT

NETCONF-638Jeff Hartley

-- quick follow up

Info:


Self Termination of NetConf Sessions Read MOI Provisioning MnS Consumer Provisioning MnS Consumer Provisioning MnS Provider Provisioning MnS Provider [1]Establish NETCONF Session [2]NETCONF <rpc> <get><filter>, or NETCONF <rpc> <get-config><source><targetDS><filter> Retrieve config [3]NETCONF <rpc-reply> <data> [4]Terminate NETCONF SessionSource: O-RAN Specification -  O-RAN.WG1.O1-Interface.0-v03.00


O-RAN-SC wiki: https://wiki.o-ran-sc.org/display/OAM/Termination+of+NetConf+Sessions 

O-RAN-SC wiki: https://wiki.o-ran-sc.org/display/OAM/Architecture+discussion+for+Non-Permanent+NetConf+Sessions 

O-RAN-SC Jira: https://jira.o-ran-sc.org/browse/OAM-1 

OpenDaylight Jira: https://jira.opendaylight.org/browse/NETCONF-638


NetConf SessionThanks JeffProcess to establish a NetConf session


Action items


1 Comment

  1. As I mentioned during the meeting, I would like to understand the rationale behind LCM for R-APPs. There are many possibilities where R-APPs will be installed in real environments: ONAP kubernetes, external kubernetes, public/private clouds (e.g. Azure ML), OpenStack and so on.
    Looking at some design documents:

    • Non-RT RIC Applications (rApps) – Modular applications that leverage the functionality exposed by the non-RT RIC Framework to provide added value services relative to RAN operation. Examples of such added value services include:
      • Driving content (Policy or Enrichment Information) across the A1 interface
      • Recommending content for the O1 interface
      • Generating “enrichment information” for the use of other rApps

    an R-APP could be anything: a ML model, service with some logic, UI, database etc.

    Different platforms have their own LCM mechanisms and building another carrier-grade cloud system for R-APPs to wrap up pacakging and deployment seems to take extremely long time with high risk.

    Our proposal is to build reference R-APPs in ONAP based on DCAE apps/cloudify. This mechanism has been already in place and fits quite good in the idea of R-APPs.

    Maybe it would be good to start with non-RT RIC and specification of R1 interface, and then based on experience with different R-APPs decide whether strict or standardized LCM for R-APPs is needed or not.

    * LCM for  X-APPs is something completely different and I am not referring to it.