1. Pages
2. …
3. Open Transport Configuration and Control Home
4. 5G-xHaul
5. 5G-xHaul Call-in Details & Notes

2022-01-19 5G-xHaul Meeting notes

00:01

CoreModel #22

Removing embedded clock attribute from logical termination point

• Please see the proposal made for 2022-01-26 (modified on 2022-01-18)
• discussion ongoing

Identities for 'switch-selection-reason' are missing

• Please see the proposal made for 2022-01-26

Identifier at the original management interface to be mapped

• Please see the proposal made for 2022-01-26

proposed position

• https://opennetworking.org/category/news-and-events/press-releases/

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 (telefonica.de)

Proposed Text for ONF context:

Another breakthrough in Software Defined Networking (SDN) for microwave transmission.

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 cost efficient, 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 a standardized management interface. The information and data models developed by ONF OTCC 5G-xHaul group resulted in a reference implementation integrating 40.000 microwave devices into an Open Daylight Controller,  operating in the Telefónica production network. 

All microwave devices in Telefónica’s mobile backhaul network are now accessible via a single harmonised API (ONF TR-532), which is the key enabler of a microservices architecture.

Special thanks to the ONF OTCC 5G-xHaul group contributors: Ericsson, highstreet technologies, Huawei, NEC, Nokia, SIAE Microelettronica, Telefónica, TechMahindra, ZTE

Further review until Friday 2022-01-21 - comments by email. 

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

xPath examples to address resources (or to group resources)

(contribution by AlexS)

1. all LTPs
   /core-model-1-4:control-construct/logical-termination-point
   
   
2. all LTP uuids
   /core-model-1-4:control-construct/logical-termination-point/uuid
   
   
3. get LTP instance by uuid (example uuid = '410dcc94-7916-11ec-90d6-0242ac120003') 
   /core-model-1-4:control-construct/logical-termination-point[uuid='410dcc94-7916-11ec-90d6-0242ac120003']
   
   
4. all AirInterfaces (meaning all LTP where the layer-protocol is "air-interface")
   /core-model-1-4:control-construct/logical-termination-point[layer-protocol/layer-protocol
   -name='air-interface-2-0:LAYER_PROTOCOL_NAME_TYPE_AIR_LAYER']
   
   TODO: Example for MW-PAC (even if MW-PAC is not considered as a resource)
   
   
5. all equipment objects
   /core-model-1-4:control-construct/equipment
   
   
6. equipment object of an OutDoorUnit
   ... under the (maybe wrong) assumption that the functional-block attribute states "outdoor-unit" 
   /core-model-1-4:control-construct/equipment[function-block='outdoor-unit']
   
   equipment  vs actual-equipment → requires further discussion - not part for examples
   
   Note 2022-02-02: The requirements/prerequisites for this xPath example are not fulfilled. Therefore, in this example the list of resource ids (equipment/uuids) must be explicit defined and exposed in the capabilities.
   
   

1. all EthernetContainer objects with a server relation to an air-interface or all LTPs where its uuid is listed as clientLTP of all LTPs where its uuid is listed as clientLTP of airinterfaces.
   /core-model-1-4:control-construct/logical-termination-point[uuid=/core-model-1-4:control-construct/logical-termination-point[uuid=/core-model-1-4:control-construct/logical-termination-point[layer-protocol/layer-protocol-name='air-interface-2-0:LAYER_PROTOCOL_NAME_TYPE_AIR_LAYER']/client-ltp]/client-ltp][layer-protocol/layer-protocol-name='ethernet-container-2-0:LAYER_PROTOCOL_NAME_TYPE_ETHERNET_CONTAINER_LAYER']
   
   remember: read "[]" as  WHERE (think of SQL)
   
   Concern: not human-readable, question: is this needed?

Please see the latest version of the proposal: https://wiki.opennetworking.org/download/attachments/265093121/proposal-sequence-id.docx?api=v2

AI Vendors: Please prepare questions to continue.

• on the agenda for next Tuesday 

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 → 

2021-05-25

• Any questions?
  • no questions

2021-06-16

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

2021-11-24

• 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

2021-12-01

• 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.
    
    

2021-12-15

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