Costa Rica face-to-face (and remote)

Time zone: UTC-06:00

Oct14 -10:15 to 11:45: Session with WG2

Lead: Dhruv Gupta

IM for A1: 

Kevin Scaggs
https://gerrit.o-ran-sc.org/r/admin/repos/scp/oam/modeling

A broader scope of the IM work

The O-RAN common information model should align the different WGs in terms of modeling, terminology, definitions, … avoiding different modeling and solutions for the same functionalities.

  • A serial number is a serial number is a serial number
  • SW management is SW management is SW management


In addition, the IM work aligns the work with 3GPP (not relevant for A1 as A1 is a pure O-RAN exercise) and addresses gaps from the operator's point of view.

What are the expected deliverables, and expectations from WG2?

WG1 IM would need input from WG2 for the object and attributes to be modeled and related use case descriptions and workflows.

PM data according to WG1 Architecture and Interface specification should be streamed via VES to SMO. Are there gaps in the VES format for PM data?


Oct15 -16:30 to 18:15: Session with O-RAN-SC ToC

Status, roadmap, use cases: 2019-10-15-ORAN-OSC_rel_A-B_WG1_OAM_O1_OIM.pptx


Oct16 -16:30 to 18:15: Session with WG1

Lead: Kevin Scaggs(Information modeling part, Papyrus); Martin Skorupski(yang)

Alignment across UML Information models

O-RAN Working group 1 (WG1) is going to provide information models for the different interfaces, which O-RAN feels responsible for. Such interfaces (APIs) are:

A1, E2, O1, O1* and OpenFronthaul.

One main target is the alignment with 3GPP models. Therefore, the main object classes are ManagedElement and ManagedFunction. Such object classes are common for all O-RAN interfaces and will be part of the O-RAN common information model.

However, the common information model must not include the A1, E2, O1, O1* and OpenFronthaul specific object classes. Those are defined, reviewed and agreed in the related working groups domains. WG1 IM takes care to create the corresponding information model. 

The result is a common information model and interface-specific submodules.


Dependencies and model hierarchy

O-RAN Common Information Model

  • A1 Information Model
  • E2 Information Model
  • O1 Information Model
  • O1* Information Model
  • OpenFronthaul Information Model


Alignment between UML information models and YANG/SWAGGER/ASN1 data models

UML visualize models and is needed to explain, share and discuss models. However, related data models will be implemented. The O-RAN Alliance Architecture and Operation and Maintenance interface specification selected NetConf/Yang as API Protocol and data schema.

As a consequence, the UML must be transformed mapped to YANG models. Ideally, there would be tooling, which simply converts UML to YANG (or others schemas). The challenge is that UML is usually much more powerful, than the schemas. For an automatic translation, mapping rules and UML guidelines are defined to "restrict" the complexity and various options of UML.

The IISOMI project (Informal Inter-SDO Open Model Initiative) has created such guidelines, rules and processes. 


Source: IISOMI

Challenges:

The UML modeler must know and respect the rules and guidelines, otherwise tooling will create invalid schemas.

Implementation, test and maintenance of rules, guidelines and tooling is more complex than it sounds. Therefore an open-source project proposal was created.


Reconcile O-RAN IM with open source project models

As O1 is concerned the VES format is developed and maintained in the open source project ONAP. Now 3GPP and therefore also O-RAN IM is looking into it. Please see https://wiki.onap.org/display/DW/VES+7.1.

For the configuration part there are several information model and data models available from different SDOs and/or open-source projects: IETF, MEF, TMF, IEEE, ITU-T, ONF, OpenROADM, OpenBackhaul, ...

Also 3GPP specifies yang modules - WG1 and WG5 are contributing feedback to 3GPP: Contribution to 3GPP TS 28.541 V16.1.0

  • No labels