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-01-13: Martin Skorupski

2020-01-20: Martin Skorupski

2020-01-27: Martin Skorupski

2020-02-03: Martin Skorupski

2020-02-10: Martin Skorupski

00:05FC VLAN Creation

RPC for FD:VLAN-FC creation

  • yang RPC- FC creation
    • input 
      • FD:uuid → to address the FD
      • vlanId → the "real" interesting parameter
    • output
      • FC:uuid

now the FC:uuid is known to all application.

The FC has no FCports at this point in time.

  • yang RCP - target: creation for FCPorts
    • input
      • FC:uuid
      • port role?!?!
      • associations to LTP(VLAN)

Continue the discussion on 2020-10-21

(TODO Sko): Add link: FC diagrams

00:25Firmware@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.

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.


Package Activation:

  • attribute vs RPC
    • RPC seams to be the way forward
      • impact on UML/UML2YANG/YANG
      • similar discussion for FC(VLAN) creation via RPC
      • UML/YANG modeling guideline uses term "operations" (not PRC)
      • investigation ongoing Package Activation will gain by the VLAN-FC creation

Parameter (status report and further discussion)

  • Package
  • Image
    • regarding "imageIdentifier" - proposal to be discarded - however feedback from vendor will drive final decision

Package and Image class should inherit from GlobalClass - same as for Profile


UML for Firmware

End of the meeting

Discussions to be continued:

O-RAN WG9 (Transport)Alex StancuWG9 made a "gab gap analysis" of the ONF-Microwave and is looking for feedback/cooperation ...
00:??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: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