Overview
Repositories managed by OAM project
- oam - main repo
- oam-nf-oam-adopter - Network Function Adopter for model and protocol conversion according to O-RAN OAM specifications.
- oam-tr069-adapter - Converts BBF-TR069 oam SOAP interface into NETCONF/YANG
- scp/oam/modeling - yang data models and yang-tools generated classes
Repositories are used to provide osgi bundles and docker images for nonrtric-o1-controller.
- feature parent for the feature bundles and distribution.
- docker images for nonrtric-o1-controller
- feature bundles for specific devicemanagers
- model bundles with classes for generated classes from yanf files, representing specific standards
Setup tasks/sub-tasks of jenkins are bundled via OAM-83 - Getting issue details... STATUS
Target environments
- ONAP Honolulu: Maven 3.8, Java 11
- ONAP Istanbul: Maven 3.8 Java 11
Structure and Jenkins jobs
The following sub structure is used:
| repo:path | Artifact group | Build results | description | Jenkins jobs |
|---|---|---|---|---|
| oam:distribution/ | docker images → nexus | Source for image creation | ci-management/jjb/oam/oam-distribution.yaml | |
| oam:docs/ | Documentation → readTheDocs | readTheDocs source | ||
| oam:features/ | org.o-ran-sc.oam.features | feature bundles → nexus | Feature bundles | ci-management/jjb./oam/oam-features.yaml oam-features-maven-verify-master-mvn35-openjdk8 |
| oam:parent/ | feature parent bundles → nexus | Parents depending on ONAP Parents | ci-management/jjb/oam/oam-parent.yaml | |
| oam:info.yaml | ci-management/jjb/oam/oam.yaml | |||
| scp/oam/modeling:features/ | org.o-ran-sc.scp.oam.modeling.features | feature bundles → nexus | yang model generated code | |
| scp/oam/modeling:info.yaml | ci-management/jjb/scp-oam-modeling/scp-oam-modeling.yaml |
Artifacts groupId "org.o-ran-sc.oam.features".
List of all artifacts as provided under this group in repository layout
org.o-ran-sc.oam.features ├── devicemanager │ ├── devicemanager-oran-ru-fh-feature │ ├── devicemanager-oran-ru-fh-installer │ ├── devicemanager-oran-ru-fh-model │ ├── devicemanager-oran-ru-fh-provider │ ├── devicemanager-oran-ru-fh-top │ ├── devicemanager-xran-ru-fh-feature │ ├── devicemanager-xran-ru-fh-installer │ ├── devicemanager-xran-ru-fh-model │ ├── devicemanager-xran-ru-fh-provider │ └── devicemanager-xran-ru-fh-top ├── features-top │ ├── 0.7.1-SNAPSHOT │ └── maven-metadata-local.xml └── parent ├── binding-parent ├── odlparent-lite ├── parent-top └── single-feature-parent
Directory oam:features containing specific devicemanagers
devicemanager - top level for devicemanager
- o-ran - Open RAN standard
- ru-fh - device related radio unit - front haule
- x-ran - X RAN standard
- ru-fh - radio unit - front haule
- tr069 - TR069 standard
Artifact ids
Using ONAP Frankfurt
Example with devicemanager xran/ru-fh for top pom file.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.onap.ccsdk.parent</groupId>
<artifactId>odlparent-lite</artifactId>
<version>1.5.2-SNAPSHOT</version>
<relativePath/>
</parent>
<groupId>org.o-ran-sc.oam.features.devicemanager</groupId>
<artifactId>devicemanager-oran-ru-fh-top</artifactId>
<version>0.7.1-SNAPSHOT</version>
<packaging>pom</packaging>
<name>o-ran-sc-features :: ${project.artifactId}</name>
<properties>
<feature-name>devicemanager-oran-ru-fh</feature-name>
</properties>
<modules>
<module>model</module>
<module>provider</module>
<module>feature</module>
<module>installer</module>
</modules>
</project>
6 Comments
Manoj Nair
Hi OAM Team/ Martin Skorupski , We found three folders under scp/oam/modeling - published,sim and working.
Can you please help to understand these folders and whether these are extended from 3GPP yang models (https://forge.etsi.org/rep/3GPP/SA5/data-models/tree/master/yang-models) or are created afresh to support O1 v3 spec of O-RAN Alliance.
Martin Skorupski
Hi Manoj, sorry for the late reponse: 3GPP created its own repo and moved away from etsi. Please see https://forge.3gpp.org/rep/sa5/MnS/ Have fun, Martin
Manoj Nair
Thank you. So O-RAN OAM repo is derived from 3GPP yang models ? Is the following understanding about O-RAN OAM yang models correct ?
published - yang models aligned with O-RAN spec
sim - Used in Simulators
working - Yang models yet to be verified/ under discussion
Martin Skorupski
O-RAN O1 interfacing augments 3GPP yang modules - however there is an ongoing debate about how open-source can use 3GPP data module due the to following copyright statements:
Source: https://forge.3gpp.org/rep/sa5/MnS/
and
-----
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© 2020, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.
---
Source: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3400
At this moment the OAM team has "implemented" and 3GPP but must not share implementations and conversions in open-source repos.
OAM does not have the intention to derived from 3GPP data models but is not allowed to reproduce them in other media (e.g. open-source gerrit)
Manoj Nair
Thanks. Can you please confirm regarding the second part of the question as well . Also what is x-ran being referred in this page ?
Is the following understanding about O-RAN OAM yang models correct ?
published - yang models aligned with O-RAN spec
sim - Used in Simulators
working - Yang models yet to be verified/ under discussion
Martin Skorupski
only the O-RAN-FH yangs for O-RUs are 100% aligned with O-RAN.
I started a debate, whether O-RAN should pulish their yang models automatically (like IETF) under
https://github.com/YangModels/yang/tree/master/standard
If you support this view (or not
) -please let me know.
regarding "sim" - with the latest update in the sim project this folder can be deleted - I'm going to discuss this view with the SIM porject
regarding "working" - the term is reused from O-RAN Alliance data model development and here it should be interpreted as "not aligned - in some cases with a potential to be aligned". maybe "experimental" would fit too.
with respect to xRan.
xRan is used for upgrade use cases - xRAN → software update → o-RAN-FH → software update → O1-component.