Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inapplicable data cannot be indicated #24

Open
michbin opened this issue Apr 13, 2022 · 3 comments
Open

Inapplicable data cannot be indicated #24

michbin opened this issue Apr 13, 2022 · 3 comments
Assignees
Milestone

Comments

@michbin
Copy link

michbin commented Apr 13, 2022

The model attaches data for both frequency synchronization and PTP to various objects, e.g. clock.

There is no way to indicate that some data might not be applicable. E.g. the PTP attributes would not be applicable if a clock only supports frequency synchronization.

Possible solutions:

  • Add when statements and attributes which can be used as "flags" (or use existing ones).
  • Define the containers as presence containers which are only present if contained data is applicable.
@openBackhaul
Copy link
Owner

End point of the discussion at the Modelling Call on 26th of April 2022:
Potentially it could make sense to define two separate values of a layerProtocolName attribute for synchronization and ptp (see also presentation).

@openBackhaul
Copy link
Owner

The current definition has layerProtocolName attributes in the PtpClockSpec and SynchronizationClockSpec classes, which shall augment the clock class. The When statement at the Augmentation is referencing an attribute, which would have to be augmented at the same time. Instead of testing, whether this is actually possible, an alternative modelling is proposed.

Potential proposal:
Without any When statement an additional ClockSpec class shall be augmented to the Clock class.
This ClockSpec class shall contain the layerProtocolName : LayerProtocolNameType attribute.
The When statements at the augmentations of the PtpClockSpec and SynchronizationClockSpec classes shall reference on the layerProtocolName attribute augmented by the ClockSpec class.
Details:

  • Create ClockSpec class.
  • Create augment (specify) from ClockSpec class to Clock class.
  • Create ClockSpec :: layerProtocolName : LayerProtocolNameType = NOT_YET_DEFINED attribute.
  • Delete PtpClockSpec :: layerProtocolName attribute.
  • Delete SynchronizationClockSpec :: layerProtocolName attribute.
  • Change specification of When statement between PtpClockSpec class and Clock class to Clock :: layerProtocolName attribute.
  • Change specification of When statement between SynchronizationClockSpec class and Clock class to Clock :: layerProtocolName attribute.

@openBackhaul
Copy link
Owner

openBackhaul commented Aug 16, 2022

Decision made at the 5G-xhaul call on 7th of September 2022:
Without any When statement an additional ClockSpec class shall be augmented to the Clock class.
This ClockSpec class shall contain the layerProtocolName : LayerProtocolNameType attribute.
The When statements at the augmentations of the PtpClockSpec and SynchronizationClockSpec classes shall reference on the layerProtocolName attribute augmented by the ClockSpec class.

Details:

  • Create ClockSpec class.
  • Create augment (specify) from ClockSpec class to Clock class.
  • Create ClockSpec :: layerProtocolName : LayerProtocolNameType = NOT_YET_DEFINED attribute.
  • Delete PtpClockSpec :: layerProtocolName attribute.
  • Delete SynchronizationClockSpec :: layerProtocolName attribute.
  • Change specification of When statement between PtpClockSpec class and Clock class to Clock :: layerProtocolName attribute.
  • Change specification of When statement between SynchronizationClockSpec class and Clock class to Clock :: layerProtocolName attribute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants