1. Pages
2. …
3. Open Transport Configuration and Control Home
4. 5G-xHaul
5. 5G-xHaul Call-in Details & Notes
6. 2019-03-13 WT Meeting Notes

Page History

• TR-532: Document is under review at OTCC level. Period ends 18 March.

• TR-541: some of the information that were present in the PHY model have been now attached to the equipment core model (manufacturing equipment information, temperature etc.). In this document the description of the mechanism about expected hardware has been formulated and team is invited to send comments.

• no update respect to last week due to activity conflict with TR reviews. Missing only finale read and few English modifications.
• We ask for volunteers for final reading and English review from people native English languages (in this call no one was present from US so we'll ask offline), otherwise Thorsten will consolidate the remaining comments for next week.

Splitting into one UML/YANG per *_Pac

Currently the TR-532 (document and UML) describes a single YANG, which comprises 6 Pacs (airInterface, airInterfaceDiversity, pureEthernetStructure, hybridMwStructure, tdmContainer, ethernetContainer).

The YANG, which is created by TR-541 (Ethernet PHY), also contains pureEthernetStructure and ethernetContainer.

It does not make sense that devices, which have microwave radio and Ethernet interfaces, implement two YANGs, which both contain the same (or even worse, different) definitions for pureEthernetStructure and ethernetContainer.

This is why it is proposed to split the big UML/YANGs in TR-532 and TR-541 into several smaller UML/YANGs, which contain one *_Pac each.

Of course, this change will not take effect on TR-532v1.1.

Discussion:

Split yang will change probably the name space of the yang files (to be checked) → Martin could check this point (no critical point for decision).

Decision:

No objection. Decision to proceed as documented in this proposal #1.

Proposal#2:
 

Referencing a repository that holds UML, YANG, Class Diagram, GenDoc Export and reference implementations

Currently TR-532 document basically contains and explains the UML.

While UML is good for modeling, most implementations are based on YANG.

YANG and reference implementations should be part of the TR.

It does not make sense printing YANG and code of reference implementations into an appendix of the TR document.

This is why it is proposed to store all these items together in a repository and to reference this repository from inside the TR document.

Together with Proposal 1: This means that the TR document would contain a list of references that together build the subject of the TR.

Hypothetical Option: The same definitions could be referenced in several TR documents with divers subjects.

Of course, this change will not affect TR-532v1.1.

Decision

No objection. Decision to proceed as documented in this proposal #2. It can be also created as well a .zip file with all components.

Action Point to G.Cazzaniga to ask ONF about official repository.

Proposal#3:
 

Widening the scope of TR-532

Currently TR-532 defines a couple of technology specific extension to the LayerProtocol/LayerTerminationPoint class.

It is not enough for configuring the entire wireless transport device.

It is also not enough for documenting the wireless transport network.

Quality and completeness of the existing definitions already reached a very high level.

This is why it is proposed to expand the coverage of the TR-532 on Connections and further Interfaces instead of focusing on updating existing *_Pacs.

Describing the Connection between airInterfaces could be a first step.

Together with Proposal 1 and 2: This means that the TR document would contain an increasing list of references that together build the subject of the TR.

Hypothetical Option: Not all the referenced definitions need necessarily to be elaborated within WTP. Analyzing definitions first and testing interworking of a selection of definitions in the PoC could accelerate provisioning of definitions.

Of course, this change will not affect TR-532v1.1.

Decision

Probably we need further discussion. We need as well to understand how does it work in practical examples.

 backward compatibility topic:

• in the TR-532 and TR-541 a sentence will be inserted.
• we are not in pressure now to have a document to fully cove the topic (wider scope).
• under discussion as well with O-RAN if there any interest on the topic.
• discussion will held when new version of the document will be provided to the team
• some offline discussion will be then necessary (focus team).