Skip to end of metadata
Go to start of metadata

Architecture, Semantic and Behavior


7am PDT | 10am EDT | 14:00 UTC | 16:00 CEST | 17:00 EEST | 19:30 IST | 22:00 CST | 23:00 JST |

Web Conference:

Please use this link (thanks to Telefonica)  


(please feel free to correct, update your names (wink) Thank you very much!!!) 

Info to: 


  • going forward

Discussion items


the attached document consolidates the content of Pawel+Martin+Alex’s AirEquipment specification into the already existing WireEquipment_1.0.0-tsp.190920.1230+spec.1.docx


  • is written in change mode so impact on existing implementations can be easily assessed.
  • represents also an update to the WireEquipment specification, with additional examples, pictures and clarifications
  • consolidates also handling of Profiles
  • tries being open for expansion on all kinds of components.

Tasks: Please review and add inline comment to the document

unitl  and latest until  .

Roberto: different configurations (e.g. 2+0, 1+1) are covered by CoreModel (serverLTPs, clientLTPs, fcSwitch)


Firmware Release and Licenses might influence Interface Capabilities #15

Currently, the characteristics expressed by the attributes at the ManufacturedThing class of the Core IM are the base for deciding, which Capability attributes to attach to a new instance of an LTP.

This expresses the dependency also to the hardware release.

Dependencies between interface Capabilities and firmware release or licenses are not documented.

Proposal 1
Currently, there is a 0..1 association from ExpectedEquipment and ActualEquipment classes to ManufacturedThing class.
It is proposed to change this towards a * association and document firmware as well as licenses also as instances of the ManufacturedThing class.
The device would then have to regard all instances of ManufacturedThing for choosing the correct set of Capability values, while instancing the LTP.

Proposal 1.1
In the plan-build-operate process, the operator has to decide, whether to document firmware and licenses.

Proposal 1.2
While plugging a new hardware component, ActualEquipment is instantiated including ManufacturedThing instances for hardware, firmware and licenses.
If there would be differences between ActualEquipment and ExpectedEquipment, the new hardware component would not become operational.

Proposal 1.1.1
If there would be no instances of ManufacturedThing for firmware and licenses at the ExpectedEquipment, status of firmware and licenses would not be regarded for deriving the operational status.

Covered by previous topic - see above

Roberto Servadio

ComboPort scenario

  • optical vs electrical
  • only one at the time
  • What is the impact on Equipment

How to express, 2 physical interfaces ending optional in a one EthernetContainer?

  • ClientLTP/ServerLTP between Structure and Interface
  • Structure with 2 physical-port-reference
  • ForwardingConstruct with ForwaredingConstructSwitch
  • combinations
  • ...

Please see Contributions by SIAE (Martin Skorupski to be added)


dropping-behavior-kind on device/switch level - link to issue - eth30

AI: Danilo PalaMichael BinderDaniela Spreafico: Please provide options how to solve the issue and a recommendation for discussion next week. 

We think there are more attributes.

Please comment the issue to get forward. 


radio-signal-id: proposal of simplification - link to issue - air39


The comment of the expectedRadioSignalID attribute should get additional phase "Only relevant, if expectedEqualsTransmittedRadioSignalID==false.".

AI: Martin think where in TR docs such "rule" are documented. 

Other similar cases:

config attribute, where the device supports only one value.

e.g. Maintenance Timer: 

should be handled in future.

AI: should be agreed in ONF 5G-xHaul.

Action items