2020-11-11 Meeting notes (ONAP/O-RAN-SC/SMO - Meeting)

00:00

Admin

@Martin Skorupski

Next meeting: 2020-11-18 @Martin Skorupskito open the bridge

2020-11-25: @Martin Skorupskito open the bridge

2020-12-02: @John Keeney (Ericsson EST)

2020-12-08: @Martin Skorupskito open the bridge

2020-12-15: ???

00:05

O-RAN-SC

O-RAN-SC PTLs

Status reports:

• SMO:

  • onboarding of packages

  • yang-model validation ongoing

    • admin-status example

• Non-RT-RIC:

  • see previous meeting minutes

  • http-proxy southbound

• SIM:

  • new repo for E2 interface data(!) useful for xApps

  • o1-sim updated (new framework) in gerrit

• OAM:

  • RestConf RFC8040 fields-filtering to NetConf Subtree filtering → contribution to ODL project - first version cheery picked for ODL Aluminum SR0

00:16

Use Case

@Swaminathan Seetharaman

Use Cases

Please see page #2 for details: 
5G Use Cases in R7 Guilin. - 

very first view - to be discussed further:

1.  BULK PM -  PM data collection and control

   • 100% aligned with O-RAN interface specification; use case was demonstrated several times
     
     

     • PM collection mechanism aligned to 3GPP
       proposal: Check updates of 3GPP pm xml file format and updates of VES messages 

1.  

   •  

     • PM subscription mechanisms aligned to 3GPP
       proposal: An update could be required in the future for an alignment with recent new 3GPP Parametricjob class 

2. OOF -SON PCI (5G)
   
   

   • use VES 7.2 - reference will be in O-RAN specs.

   • use 3GPP NRM - see https://forge.3gpp.org/rep/sa5/MnS/

3. 5G SERVICE MODELING & DEFINITION (5G)

   •  UC under analysis 

     • use VES 7.2 - reference will be in O-RAN specs.

     • use 3GPP NRM - see https://forge.3gpp.org/rep/sa5/MnS/

     • open: Integration of A1, O2, R1 interfaces and specifications from O-RAN

4. CONFIGURATION PERSISTENCE SERVICE (CPS)

   • ONAP provides a  persistency data service that can be used for any XNF configuration data (Poc in Rel G, new ONAP component in Rel H)

   • CPS is model driven and it may use any YANG model adopted by any xNF (e.g.  3GPP YANG models and vendor extensions)   

   • open: is the abstraction by 3GPP and O-RAN sufficient for all the targeted use case - how do µServices, rApps make use of C&PS, if C&PS is device model driven and not service model driven?

   • Idea: Contribution of consumer view

     • @gasparini24 to carry forward (thanks)

     • xPath to identify CPS data

     • Abstraction layer added to CPS but outside of CPS

5. xNF LICENSING MANAGEMENT

   • not subject of O-RAN (yet)

   • proposal: defer or contribute terms, definitions, specifications to O-RAN

6. ONAP/3GPP & ORAN Alignment

   • O-RAN O1 data models are augmenting 3GPP data models

   • A1, R1, O2 data models are subject of O-RAN only

7. ONAP/ORAN Alignment -A1 adapter
   
   

   • Detailed alignment/collaboration needed with O-RAN-SC Non-RT-RIC project (For details please reach-out to @John Keeney (Ericsson EST))

     • testing: please include @Lasse Kaihlavirta

8. 5G NRM Simulator in ONAP (CM)

   • CM is part of O-RAN OAM Architecture and OAM interface specification
     proposal: as a staring point the 3GPP NRM yang models V16.0.5 from July 2020 should be used - for VES the version 7.2 is specified.  

   • note: 5G NRM is not a ONAP Rel G UC

9. E2E NETWORK SLICING (5G Use Case)

   • Network Slicing is not part of 3GPP NRM so far
     proposal: waiting for 3GPP and O-RAN specifications  - V17 draft is available

10. PNF sw upgrade in ONAP is aligned to ORAN O1 specification

11. xNF Package and onboarding in ONAP
     -   xNF Package complaiant to ETSI SOL004,
    -    additional xNF artifacts have been introduced and supported: 
                  -  VES event, and PM dictionary artifacts according to VES event registration specifications
                  -  Additional artifacts (e.g. xNF YANG model)

12. VES specification are defined by ONAP in  VNF requirement project

13. Control Loop in TOSCA PoC 

    1. A Control Loop and Control Loop components havw been defined in TOSCA and deployed

Feedback from @John Keeney (Ericsson EST): Request for chat for such use cases in Honolulu. 

00:37

@Mahesh

Application Package Structure

• TOSCA 

Info from @Michela Bevilacqua

• ONAP enhanced TOSCA 

• API schema definition for YANG and VES

On the agenda for next week - thanks!!! 

@Zu Qiang presenting ONAP on-boarding package

• (Started at approx 00:34 in recording)

• Presentation:
  
  

00:55

Questions and Answers

• O1 preparation on O-DU → code review 

END

Backup

00:10

Mahesh

Postman scripts to interface with the SMO and in turn test O1 interface between the SMO and different parts of O-RAN instances of O-CU, O-DU, O-RU and RIC using these models. 

• yang modules

• framework for test and validate CM 

share content in in SMO gerrit and create wiki linking to the same source

• Working on a framework for vendors for OAM/YANG tests

• O-RAN-SC to host the framework

• Postman and vsCode as RestClients

• Alex about to setup a SIM in OSC lab - involve Rittwik in a O-RAN private lab

• OpenFronthaul

• 3GPP models are considered.

Feedback from Rittwik

• SMO in T-Labs

• how to run Netopeer server - req to Felix (O-RAN-SC INT PTL)

• Alex asked for VMs 

Init script (Postman) for O-RAN OAM FH M-Plane (o-ran-interface.yang augmenting ) interface demoed

RFC8040 (RestConf by IETF) support supported by ODL

00:25

@Konrad Bańka

Konrad is absent this week. The presentation will be made when Konrad is available.

O-RAN Component deployment

The question is: How to deploy the red colored CNFs/VNFs of the O-RAN-Architecture?

• CNF for O-RAN-components 

  • model of CNF - how to be configured, how many components, blueprints

  • CDS model needs to be created

  • Network-service based on several CNFs

    • CNF types

      • Near-RT-RIC

      • O-CU-UP

      • O-CU-CP

      • O-DU

For detailed discussion the following page was created:

• CNF deployment of O-RAN Components 

Package

• for Network Functions (priority)

• for Network Service (second step)

CNFs or VNFs

• both should be considered 

  • let's start with CNFs first

  • VNF is considered as additional option

• no CNFs and VNFs combined in a single package

  • maybe not for rApps → 

  • VNF should take care about internal CNFs