Skip to end of metadata
Go to start of metadata

 | 2am PST | 5am EST | 10:00 UTC | 10:00 GMT | 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!!!) 

Discussion items

00:00Chair topic 
no update 



2022-01-12: Martin Skorupski

2021-01-19: Martin Skorupski

2021-01-26: Martin Skorupski

2021-02-02: Martin Skorupski


CoreModel #22

@Prathiba Jeevan

Removing embedded clock attribute from logical termination point

  • Please see the proposal made for 2022-01-26 (modified on 2022-01-18)
  • discussion ongoing
00:10CoreModel #23Daniela Spreafico 

Identities for 'switch-selection-reason' are missing

  • Please see the proposal made for 2022-01-26
00:15Equipment #16@Andreas Lattoch

Identifier at the original management interface to be mapped

  • Please see the proposal made for 2022-01-26
00:25Text for ONF @Andreas Lattoch

proposed position

Related Press Release

-  Milestone in Software-Defined Networking (SDN): o2 / Telefónica uses new standardized SDN interface for 30,000 microwave links | Telefónica Deutschland (

Proposed Text for ONF context:

Another breakthrough in Software Defined Networking (SDN) for microwave transmission, achieved by Telefónica Germany

Mobile network automation presents a significant opportunity for the telecom industry to further reduce cost and improve service quality.  With thousands of network elements, the radio access network is a prime area of focus for automation innovation by mobile operators today.

An essential component of modern mobile network deployments, microwave links provide a low cost, rapid deployment option to connect radio units that can be sited for optimal coverage and performance.  As 5G networks continue to grow, this flexibility becomes more important and the volume and complexity of mobile backhaul continues to increase, placing ever more value on mobile network automation.

Achieving automation of microwave transmission requires the harmonisation and standardisation of the network element management interface.  Telefónica continues to lead the industry towards this standardisation, having now completed the integration of over 40,000 microwave nodes from multiple vendors into their Open Daylight Controller utilising a common Open Network Foundation ONF TR-532 interface standard. 

In realising this goal, Telefónica has unleashed the potential of SDN automation for its microwave transmission network.  All microwave devices in Telefónica’s mobile backhaul network are now accessible via a single harmonised API, a key enabler for of a microservices architecture that will facilitate easy adoption of future automation functions over time. 

Our special thanks to our partners involved in achieving this great outcome.  Network partners - Ericsson, Huawei, SIAE, ZTE.  Technology Partners - TechMahindra, Wipro.  Open Daylight Controller (ODL) partners - highstreet technologies, FRINX.


Centralized alarm list

(alarm definition, capability and notification)

Continue UML Modeling

  • severity assignment 
  • use case description for severity assignment
    • ... or can the severity be calculated on a higher layer (OSS, BSS)?


  • Alarm severity configuration is required
    • per alarm type
    • per alarm type and resource-type (alarm-emitter-object-class)
    • per alarm instance (alarm type and resource) 
  • default severity exists on the node in advance - there is not need to change it but an option to change the alarm severity



@Alexander Wenk


Input by Prathiba:


  • target for yang  2021-12-15
  • augment LTP for embeddedClock in sync
00:00ltpName @Andreas Lattoch

Please see new created issue for this topic

00:00Relation between planning and actual data from the network

Please see the latest version of the proposal:

AI Vendors: Please prepare questions to continue.

  • on the agenda for next Tuesday 
00:35Mediator Instance Manager

Pre- Discussion happened yesterday 

  • info send by Thorsten on Monday 2021-05-177
  • in addition Thorsten will send the "background discussion slide"....

Mediator Instance Manager 

  • What is the protocol? NETCONF or REST or RESTCONF or ...
    • Working Assumption:  not decided
    • SIAE would like to decide based on efforts after analysis. 
    • UML include the "service" - but not the operational and maintenance layer
    • YAML (OpenAPI3) → UML (papyrus) → YANG → 


  • Any questions?
    • no questions


  • please see "App layer on top of the SDN controller" above.


  • Introduction to the topic 
  • functional requirements
  • how to address security constrains and its key management
  • impact on MediatorInstanceManager
    • including logging mechanism
  •  option to reuse code provided by TEF


  • Create Mediator Instance
    • Q: Is device-port missing?
    • A: no - because this is knowledge of the Mediator-Instance
    • (Management) Protocol and protocol version and other protocol configuration parameters : depend on 'device-kind-name'.
    • Further Configuration comes as general configuration with the "LoadFile" (e.g. NETCONF port range, SNMP version, SNMP TRAP port)

    • Q: Release version for in device parameters?
    • A: also here the mediator implementation knows what to do. 

    • Q: device-kind-name: enum vs. string
    • A: type sting → ok but known values must be agreed between vendor and operator OPEN...... to be continued tomorrow.


  • some "security" findings by TEF IT - to be addressed - some repos changed to "private" - access by git invitations - please send github accounts to Thorsten. 

Action items