Versions Compared

Old Version 6

changes.mady.by.user Martin Skorupski

Saved on

compared with

New Version Current

changes.mady.by.user Martin Skorupski

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: update according to ODUHIGH-322

Table of Contents

Scope

The page will discuss and document the necessary yang modules to be supported by O-DU to ensure the end-to-end functionality of the D-Release use case "Closed loop". 

As O-RAN alliance does not provide solid yang models yet, other data models needs to be defined or selected.

Idea

Decisions

From SMO point of view the O-DU should provide a capability to "manage" the expected NetConf Server connections (O-RAN OpenFronthaul M-Plane) representing O-RUs.

The O-RU will connect via NetConf Call Home/TLS to the O-DU. Therefore the O-DU must be configured in advance with the public key of potential O-RUs.

Exactly this function is implemented by the OpenDaylight project and YANG modules to mimic a potential O1 interface are available.

However, OpenDaylight also supports pre-configured NetConf servers with all its connection related details and NetConf Call Home via SSH. Those parameters and object classes could be ignored for the O-RAN-SC D-Release Use Case.

Minimum parameter set to be supported

The following yang tree shows only a necessary (to be discussed) selection of parameters within the yang capabilities of OpenDaylight forconfiguration and  supervision of NetConf Servers by a NetConf Client (O-DU).

Code Block
languageyml
module: network-topology +--rw network-topology +--rw topology* [topology-id] +--rw topology-id topology-id +--rw node* [node-id] | +--rw node-id node-id | +--ro nettop:available-capabilities | | +--ro nettop:available-capability* [] | | +--ro nettop:capability? string | | +--ro nettop:capability-origin? enumeration | +--ro nettop:unavailable-capabilities | | +--ro nettop:unavailable-capability* [] | | +--ro nettop:capability? string | | +--ro nettop:failure-reason? enumeration module: odl-netconf-callhome-server +--rw netconf-callhome-server +--rw allowed-devices +--rw device* [unique-id] +--rw unique-id string +--rw (transport)? | +--:(ssh) | | +--rw ssh-client-params | | +--rw host-key string | | +--rw credentials! | | +--rw username string | | +--rw passwords* string | +--:(tls) | +--rw tls-client-params | +--rw certificate-id string | +--rw key-id string +--ro callhome-status:device-status? enumeration

In SMO project call on 2021-03-04 it was decided to create a yang modules for O-RAN-SC DU with a minimum parameter set supporting the D-Release Closed loop use case.

The initial idea of a configuration for the O-DU NetConf client is rejected, because in D-Release there wont be a NetConf client implemented on O-DU.

The prototype yang models from B-Release wont be enhanced.

RSAC 2021-04-08

Please see comment in 

Jira Legacy
serverSystem Jira
serverId3122c0e4-6090-3a7d-9725-8b5a32a8eaeb
keyODUHIGH-322
 and related gerrit review.


D-Release YANG model for O-DU

Please see attached hello-world yang for D-Release.

module: o-ran-sc-du-hello-world
  +--rw network-function
     +--rw du-to-ru-connection* [name]
        +--rw name string
        +--ro operational-state? enumeration
        +--rw administrative-state? enumeration
        +--ro cell-state? enumeration
        +--ro status? connection-status


rpcs:  // comment: both RPCs are marked as deprecated
               // its function is covered by administrative-state.
  x---x connect
  | +---w input
  | | +---w remote-network-function o-ru-reference
  | +--ro output
  | +--ro response-status enumeration
  | +--ro message? string
  x---x disconnect
     +---w input
     | +---w remote-network-function o-ru-reference
     +--ro output
        +--ro response-status enumeration
        +--ro message? string