This Annex provides guidelines on the use of certain specific IEEE parameters and protocol messages in the case of TSN as described in clause 5.27.

The ingress timestamp (TSi) of the PTP event (e.g. Sync) message is provided from the ingress TT (NW-TT/UPF or DS-TT/UE) to the egress TT, if supported in the PTP messages as described in clauses 5.27.1.2.2.1 and 5.27.1.2.2.2 using the Suffix field defined in section 13.4 of IEEE Std 1588 [126]. The structure of the Suffix field follows the recommendation of section 14.3 of IEEE Std 1588 [126], with an organizationId specific to 3GPP, an organizationSubType referring to an ingress timestamp, and data field that carries the ingress timestamp encoded as specified in section 5.3.3 of IEEE Std 1588 [126]. TS 24.535 specifies the coding of the ingress timestamp in the (g)PTP messages between a DS-TT and a NW-TT.

The procedure described in this clause is applicable if DS-TT and NW-TT support operating as a boundary clock or as a time-aware system or as peer to peer Transparent Clock or end to end Transparent Clock, and when the PTP instance in 5GS is configured to operate as a time-aware system or as a Boundary Clock or as peer to peer Transparent Clock or as end to end Transparent Clock. Whether DS-TT/NW-TT support operating as a boundary clock or peer to peer Transparent Clock or end to end Transparent Clock or as a time-aware system (support of the IEEE Std 802.1AS [104] PTP profile) may be determined as described in clause K.2.1. PTP ports in DS-TT and NW-TT may support the following delay measurement mechanisms:

• Delay request-response mechanism as described in section 11.3 of IEEE Std 1588 [126];
• Peer-to-peer delay mechanism as defined in section 11.4 of IEEE Std 1588 [126];
• Common Mean Link Delay Service.

Depending on the measurement mechanisms supported by DS-TT and NW-TT as well as the configured clock mode of 5GS, the PTP ports in DS-TT and NW-TT are configured as follows:

• PTP ports configured to operate as a time-aware system according to IEEE Std 802.1AS [104] may be configured to use the peer-to-peer delay mechanism or Common Mean Link Delay Service;
• PTP ports configured to operate as a Boundary Clock according to IEEE Std 1588 [126] may be configured to use the delay request-response mechanism, the peer-to-peer delay mechanism or Common Mean Link Delay Service.

PTP ports in 5GS configured to operate as a peer-to-peer Transparent Clock according to IEEE Std 1588 [126] shall use the peer-to-peer delay mechanism. PTP ports in 5GS configured to operate as an end-to-end Transparent Clock according to IEEE Std 1588 [126] do not actively participate in path and link measurements mechanisms but shall calculate and add residence time and delay asymmetry information to PTP messages as defined in section 10.2.2 of IEEE Std 1588 [126]. If DS-TT and NW-TT support operating as an end-to-end Transparent Clock, then the residence time for one-step operation as an end-to-end Transparent Clock for the path and link measurements is calculated as follows:

• Upon reception of a PTP Delay_Req/Pdelay_Req/Pdely_Resp message from the upstream PTP instance, the ingress TT (i.e. NW-TT or DS-TT) makes an ingress timestamping (TSi) for the message.
• The ingress timestamp is conveyed to the egress TT via the PDU Session as described in clause H.2.
• The PTP port in the egress TT then creates egress timestamping (TSe) for the PTP message for external PTP network. The difference between TSi and TSe is considered as the calculated residence time spent within the 5G system for this PTP message expressed in 5GS time. If needed, the PTP port in the egress TT convert the calculated resident time in 5GS into the residence time expressed in PTP GM time e.g. by means of the factor as specified in Equation (6) of section 12.2.2 of IEEE Std 1588 [126].
• The PTP port in the egress TT modifies the payload of the PTP Delay_Req/Pdelay_Req/Pdelay_Resp message that it sends towards the downstream PTP instance as follows:
  • Adds the calculated residence time to the correction field.
  • Removes Suffix field that contains TSi.

If DS-TT and NW-TT support operating as an end-to-end Transparent Clock, then the residence time for two-step operation as an end-to-end Transparent Clock for the path and link measurements is calculated as follows:

• Upon reception of a PTP Delay_Req/Pdelay_Req/Pdelay_Resp message from the upstream PTP instance, the ingress TT (i.e. NW-TT or DS-TT) makes an ingress timestamping (TSi) for the message.
• If the ingress TT receives a Pdelay_Resp message with the twoStepFlag set to FALSE, then the ingress TT modifies the twoStepFlag to TRUE and creates a PTP Pdelay_Resp_Follow_Up message.
• The ingress timestamp is conveyed to the egress TT via the PDU Session as described in clause H.2.
• The PTP port in the egress TT then creates egress timestamping (TSe) for the PTP message for external PTP network. The difference between TSi and TSe is considered as the calculated residence time spent within the 5G system for this PTP message expressed in 5GS time. If needed, the PTP port in the egress TT converts the calculated residence time in 5GS into the residence time expressed in PTP GM time, e.g. by means of the factor as specified in Equation (6) of section 12.2.2 of IEEE Std 1588 [126]. The egress TT then stores the calculated residence time expressed in PTP GM time and removes Suffix field that contains TSi before sending the PTP Delay_Req/Pdelay_Req/Pdelay_Resp message towards the downstream PTP instance.
• Upon reception of the PTP Delay_Resp message associated with the PTP Delay_Req, the egress TT for the PTP Delay_Req message (i.e. the ingress TT for the PTP Delay_Resp message) modifies the payload of the PTP Delay_Resp message that it sends towards the ingress TT of the PTP Delay_Req message (i.e. egress TT for the PTP Delay_Resp message) as follows:
• Adds the (previously stored) calculated residence time to the correction field.
• Upon reception (or local creation) of the PTP Pdelay_Resp_Follow_Up message associated with the previously received PTP Pdelay_Resp message, the ingress TT for the PTP Pdelay_Resp_Follow_Up message modifies the payload of the PTP Pdelay_Resp_Follow_Up message that it sends towards the egress TT for the PTP Pdelay_Resp_Follow_Up message as follows:
  • Adds the (previously stored) calculated residence time of the associated PTP Pdelay_Req message to the correction field.
• Upon reception of the PTP Pdelay_Resp_Follow_Up message associated with the PTP Pdelay_Resp, the egress TT for PTP Pdelay_Resp_Follow_Up message modifies the payload of the PTP Pdelay_Resp_Follow_Up message that it sends towards the downstream PTP instance as follows:
  • Adds the (previously stored) calculated residence time of the associated PTP Pdelay_Resp messages to the correction field.

As described in clause 5.27.2, the calculation of the TSCAI relies upon mapping of information for the TSN stream(s) based upon certain IEEE standard information. Additional traffic pattern parameters such as maximum burst size and maximum flow bitrate can be mapped to MDBV and GFBR. The traffic pattern parameter determination based on PSFP (IEEE Std 802.1Q [98]), when available, is as follows:

• Periodicity of a TSN stream is set equal to StreamGateAdminCycleTime if there is only one StreamGateControlEntry with a StreamGateStatesValue set to Open in the StreamGateAdminControlList. If there is more than one StreamGateGateControlEntry with a StreamGateStatesValue set to Open in the StreamGateAdminControlList, then the Periodicity of the TSN Stream is set equal to sum of the timeIntervalValues from the first gate open instance to a next gate open instance in the StreamGateAdminControlList. For aggregated TSN streams with same periodicity and compatible Burst Arrival Times, the periodicity of the aggregated flow of these TSN Streams is set equal to StreamGateAdminCycleTime received from CNC for one of the TSN streams that are aggregated.
• Burst Arrival time of a TSN stream at the ingress port is determined based on the following conditions:
  • The Burst Arrival Time of a TSN Stream should be set to StreamGateAdminBaseTime plus the sum of the timeIntervalValues for which the StreamGateStatesValue is Closed in the StreamGateAdminControlList until the first gate open time (i.e. until StreamGateStatesValue set to Open is found). If the StreamGateStatesValue is Open for the first timeIntervalValue, then the Burst Arrival time is set to StreamGateAdminBaseTime. For aggregated TSN streams, the arrival time is calculated similarly, but using the time interval to the first StreamGateStatesValue that is Open from the aggregated TSN streams.
• Burst Size of a TSN stream at the ingress port (which is useful to map to MDBV) is determined based on the following conditions:
  • The Burst Size may be determined from TSN Stream gate control operations in the StreamGateAdminControlList. If in the StreamGateAdminControlList, IntervalOctetMax is provided for a StreamGateControlEntry with an "open" StreamGateStatesValue, the Burst Size is set to the IntervalOctetMax for that control list entry. If IntervalOctetMax is not provided, the Burst Size is set to the timeIntervalValue (converted from ns to s) of the StreamGateControlEntry with an "open" StreamGateStatesValue multiplied by the port bitrate.
  • When multiple compatible TSN Streams are aggregated, the Burst Size is set to the sum of the Burst Sizes for each TSN stream as determined above.
• Maximum Flow Bitrate of a TSN stream (which is useful to map to GBR) is determined as follows:
  • The Maximum Flow Bitrate of a TSN Stream is equal to the summation of all timeIntervalValue (converted from ns to s) with StreamGateStatesValue = Open, multiplied by the bitrate of the corresponding port, and divided by StreamGateAdminCycleTime. For aggregated TSN streams, the same calculation is performed over the burst of aggregated streams (calculated using superposition, i.e. timeIntervalValue with StreamGateStatesValue = Open of every stream is summed up, as they are assumed to have same periodicity, compatible Burst arrival time, and same traffic class if they are to be aggregated.
    When CNC configures the PSFP information to the TSN AF, the TSN AF may use local information (e.g. local configuration) to map the PSFP information to an ingress port and/or egress port of the 5GS bridge.