Stacking of Synch and PTP LTPs

[openBackhaul]

It shall be defined and documented, which kind of LTP shall serve the Synch LTPs.

Complementing the description in the Open Model Statement as it has been defined in Synch issue#48 might support solving the problem.

[niloda]

In chapter 11.1.1 ESMC operation with link aggregation of ITU-T G.8264 (08/2017) the concept of a "bundle" is introduced in cases where multiple timing links share the same synchronization source clock (the concept is borrowed from ITU-T G.781 - 5.13.2 Between NEs with SEC type clocks). The concept applies to the radio physical link aggregation (L1 aggregation). Therefore, even if the quality level is transported via Ethernet packets, where multiple parallel links share the same Ethernet Synchronization Messaging Channel (ESMC), it follows that the Ethernet container is not suitable for use as a synchronization LTP server (for frequency synch).

[openBackhaul]

There are different implementations in regards with the Layer1Aggregation:
Some implementations have ...

• ... one clock for every link in an Layer1Aggregation (Air/WireInterface would be server)
• ... one clock for all the aggregated links (EthernetContainer would be server).

As restricting putting the Synch LTPs just on either Air/WireInterface, or EthernetContainer is not able to cover both kinds of implementations, it is not a real option.
It seems there is no other way than to allow putting it on both Air/WireInterface, or EthernetContainer.
This represents a low level of harmonization and will impact usability of the modelling.

TO BE DISCUSSED NEXT: Are there any options to mitigate the impact on the user:

• Can we add conditions to the rule, so it becomes more transparent?
• Does it make sense to introduce some Capability attributes making the system behavior more predictable?
  ...
• While deciding about the modeling, we need to regards the effect in case of Layer2Aggregation, too.

[openBackhaul]

During the LF ONMI x-haul call on 2nd of July 2025:
We decided to put the issue on hold, because:

• It is unclear whether the differences in the data structure, which are expressing the differences in the hardware's implementation, will be seen as a problem during actually applying the individual management interfaces.
• It is unclear, which aspects and needs will be relevant at a solution (e.g., harmonized client/server relationship, capability attribute etc.).