Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


6am PST | 6am EST | 10:00 UTC | 11:00 CET | 12:00 EET | 15:30 IST | 18:00 CST | 19:00 JST |

Web Conference:



(please feel free to correct and update your names (wink) Thank you very much!!!) 

Info to: 


  • going forward

Discussion items

00:00chair topic 
no update 



Next meetings

2020-12-02: Thorsten Heinze

2020-12-09: Martin Skorupski

2020-12-16: Thorsten Heinze(@Alex Stancu for meeting minutes)Alex Stancu

2020-12-23:  Thorsten Heinze(@Alex Stancu for meeting minutes)cancelled

2020-12-30: ???cancelled

2020-01-06: canceled cancelled

2020-01-13: Martin Skorupski

00:05INFO: Demo Day

2020-12-03 16:00 CET- 18:00 CET

Joint PoC "Proof of Concept" O-RAN/OSC/ONAP

Recording and slides: https://wiki.o-ran-sc.org/display/OAM/Use+case+demonstration00:10
In VlanInterface historical-performance-data attribute name to be corrected

The following issue incl. proposal has been introduced


Decision has been scheduled for 9th of December.

00:15Firmware@Eduardo Yusta

Eduardo explained his proposal about how to describe firmware (https://groups.google.com/a/opennetworking.org/g/wireless-transport/c/3BJHnPa5PRU) and addressed a couple of questions to the vendors.

Vendors gave details about their implementations.

Thorsten explained two different ways of modeling Eduardo's proposal.

AP Thorsten Heinze: List attributes in Excel and send Excel to vendors to mark supported attributes. (done)

AP all vendors: Respond until Monday e.o.b. so discussion about way of modelling can be continued on Tuesday 8th of December

Working assumption

  • package/name and package/version are "key-attributes" - to uniquely identify the software package.
  • packages has status attributes
  • package has indications running on a bank
  • no object type of banks
  • max two banks
  • Continuing the discussion about firmware. NEC provided input and it was consolidated in the proposal.

    How to activate a software package: leaf or RPC?

    Discussions still needed, RPC is preferred, need to see how to model and how to integrate in our processes (Papyrus, UML2YANG etc.)

    Alex Stancu to provide example from O-RAN FH model about how it is done in o-ran-software-management; then we can assess how we can adapt it to our needs.

    SIAE is checking if RPC is feasible; Nokia will also do some checking.     → maybe RPCs will be useful in other situations as well, we need to see

    Do we need also a Download RPC? Probably. But this could be considered outside of the package model, does not really influence the inventory part.

    Is ImageName (string) and ImageVersion (string) combination enough for uniquely identify a software image?

    ImageSize proposed to be eliminated. No objections.

    ImageClass - need tot see what happens if the case vendors do not support it; same for ImageIdentifier

    ImageComparison proposed to be eliminated. No objections.

    Need further discussions.

    same package can be downloaded to both banks

    End of the meeting

    Discussions to be continued:

    00:00VLAN FC creationThorsten Heinze

    Creation of objects

    S1 use case

    • new VLAN must be configured
    • VLAN FC needs to be created
    • generation of IDs for local-ids and uuids
    • Up to know the idea is that the Device is the master of object identification
      • main reason: mediator alignment/synchronization with the device
    • Process
      • first LTP for VLANs must be created → with a given identifier
      • second FC for VLAN is created → with a given identifier
    • minimum requirement for FC(VLAN)-uuids
      • unique within the ForwardingDomain(VLAN) device
    • 3 proposals by E///
      • VLAN-ID → FC identifier
        • drawback - same id for different object times (not universal unique) - unique "only" per device/object-type
          • so not a big limitation
      • specific pattern for identifier values, to indicate that the server will later sign the final value
        • Example: :NEW:
        • NetConf client needs to accept in the response a different identifier at least must re-synch
        • Similar tasks expected for the NetConf Server
        • netconf:merge vs netconf:create
          • in both cases the identifier must be given
          • NetConf server will use the given identifier
            • seems to be impacting NetConf Server Platform implementations 
      • Define a specific VLAN-FC-Creation RPC → Action 
        • RPC for entire object creation (except the identifier)
          • Device can then define the final identifier
          • Object Creation Notification required for the VLAN-FC (as in all other cases too)
        • two procedures
          • create empty FC first, then add later the interfaces references
          • give interface reference as property to the creation RPC
        • Alternative: RPC to get the next valid identification value
          • function generateVlanFCuuid( parameter: vlanId )

    new proposal by SIAE:

    In order to provide to the application the "next" uuid an option could be the following:

    1) Add in the model in the section "status" the "next-uuid" parameter

    2) In case this "next-uuid" is influenced by some value: add in the section "configuration" the corresponding "influencer" values

    i.e. with reference to the VLAN creation, in VlanFd we could have something like:

    - In section "configuration": "next-vlan-fc-vlan-id"

    - In section "status": "next-vlan-fc-uuid"

    00:00Issues in General

    INFO: https://github.com/openBackhaul/core/wiki/summary-of-issues



    @Eduardo Yusta

    Use case discussion challenging the model proposal:

    Please see updated slides (thanks Eduardo).


    Feedback from vendors:

    • working assumption: (running) Firmware pointing to (actual) Equipment
      • assumption
        • 2 banks (logical structure of firmware)  
          • on running bank → list of firmware
            • some of the unused → those wont have an associations to (actual) Equipment 
        • Question: is the "top-level" firmware a "bank"?
          • software packages → 1 and 2 → bank 1 and 2 → or active/inactive → top-level firmware.
          • Consideration: firmware without software package
    • SIAE: option to implement in addition also pointer from Equipment to Firmware

    Firmware inventory

    • UML and yang creation 

    Firmware operations

    • download, activation, upgrade, downgrade
    • terms and definitions, needed before UML and yang

    As a result of the discussion about Firmware, their might be a need for a "restart" trigger.

    The "software activation trigger" usually also leads to a "restart" but with new software, which a "restart" reboots using the currently running software.

    Other terms for the same? or similar? function:

    • cold start (Power down, power up; traffic loss for sure)
    • warm start (restarting software - may have - may not have traffic loss)
    • reboot - this term should not be used as it is not clearly defined/used

    • (factory) reset (configuration is lost) - not a field/remote-controller operation → LCT operation → should not be covered in your API models


    • Is a "cold start/warm start" trigger beneficial on ControlConstruct level only?
    • Is a "cold start/warm start" trigger beneficial on Equipment level only? There are devices offering such options:
    • both?

    General reboot

    • cold start / warm start on device level

    @Eduardo YustaLicense Management


    • Are License be updated during life time of the device?
      • Answer: yes - there are such cases, particularity for feature enhancements or for later enabling a license - xPIC may come later, when the second link is deployed.
    • Understanding association between License Firmware, LTP, Hardware, Features/Function?
    • Do all devices require a license? 
    • Is a "feature-key" a "License" - from functional point: yes
    • What kind of License types needs to be supported - Software, Hardware, Interface, LTP, Capacity, Features, Function, ....
      • Frist idea: focus on interface-capabilities

    First proposal:

    • ControlConstruct
      • LicenseList
        • License
          • Name
          • Type
          • Description
          • key (value; hash to be checked against, ...)
          • additional-configuration - (e.g. max capacity is xyz MBit/s)
          • State: activated; expired, no-active, ....
          • pointing to "something"



    PureEthernetStructure, HybridMwStructure

    Daniela Spreafico

    Please see email_

    Please see related issues:

    Please confirm by email to Martin Skorupski by end of this week (Nov6) that keeping FM and PM for xyzStructure is ok?

    Status: positive feedback to keep it as it is:

    Decision: we keep xyzStructure as they are and close the issues above.

    00:00Centralize RMON counters

    RMON counter

    • RMON counter in ETH-Container, while others are in MAC-Interface
    • Open question: Where centralize the RMON counter
    • Working assumption: All RMON counters should be part of the EthernetContainer_PAC (Status and PerformanceMonitoring)
    • Next Step: 
      • update related ETH and MAC issues in OpenBackhaul for final proposal
      • AI Martin Skorupski consolidate proposed solutions 


    Support is welcome to consolidate with respect to RMON

    00:00Layering discussion (FCs, FDs etc.)Thorsten Heinze
    • Will publish in wiki the latest slide which is the result of discussions:
    • View file
      nameslides to be published.pptx
    • link to the contribution: 2020-09-16 5G-xHaul Meeting notes

    • Continue discussion from last week
    • Question:
      • 1x VLAN FD and 2x VLAN FC
        • Impact on MAC interfaces
    • 1:1 betweeen VLAN-IF-LTP and EthernetContainer-LTP
    • 1x physical → only one MAC-Interface?
    • MacSwitch attributes: mac-address-learning, aging-time - are such attributes sufficient to instantiate a new FD/FC objects.
    • MacFC could give a better overview - further clarifications

    Agenda: 2020-09-30

    Discussion and agreement about the following proposal:


    The following aspects are proposed to be decided by the 5G-xhaul subproject.

    -          The ForwardingDomain shall be interpreted as a Potential for Forwarding (e.g. SDH Matrix).

    [sko] Potential: something which allows the creation of “forwarding” based in the FD:LTP

    -          The ForwardingConstruct shall be interpreted as an Actual Forwarding (e.g. Connection between two VC-12 endpoints at the SDH Matrix).

    [sko] Actual: configured Forwarding – check operational states and traffic flow

    -          There might be 0 .. * ForwardingConstructs inside a ForwardingDomain.

    [sko] ok

    Discussion on dependencies between LTPs, FD, FC and between the layers will continue...

    Agenda: 2020-10-07

    • Last week we started discussing a HUB presentation using FD and FCs: but there are several ways to represent a HUB: Depending on the chosen representation there are different consequences. ... (see attachment: link)

    Action items