Section: 5.27.1.2.2 Distribution of grandmaster clock and time-stamping
Content: 5.27.1.2.2.1 Distribution of gPTP Sync and Follow_Up messages The mechanisms for distribution of TSN GM clock and time-stamping described in this clause are according to IEEE Std 802.1AS [104]. NOTE 1: It means Externally-observable behaviour of the 5GS bridge needs to comply with IEEE Std 802.1AS [104]. For downlink Time Synchronization, upon reception of a downlink gPTP message from NW-TT port in Follower state, the NW-TT makes an ingress timestamping (TSi) for each gPTP event (Sync) message and uses the cumulative rateRatio received inside the gPTP message payload (carried within Sync message for one-step operation or Follow_up message for two-step operation) to calculate the link delay from the upstream TSN node (gPTP entity connected to NW-TT) expressed in TSN GM time as specified in IEEE Std 802.1AS [104]. NW-TT then calculates the new cumulative rateRatio (i.e. the cumulative rateRatio of the 5GS) as specified in IEEE Std 802.1AS [104] and modifies the gPTP message payload (carried within Sync message for one-step operation or Follow_up message for two-step operation) as follows: - Adds the link delay from the upstream TSN node in TSN GM time to the correction field. - Replaces the cumulative rateRatio received from the upstream TSN node with the new cumulative rateRatio. - Adds TSi in the Suffix field of the gPTP packet as described in clause H.2. The UPF/NW-TT uses the ingress port number of the NW-TT, and domainNumber and sdoId in the received gPTP message to assign the gPTP message to a PTP instance in the NW-TT. If the NW-TT does not have a matching PTP instance, the UPF/NW-TT discards the message. The UPF/NW-TT then forwards the gPTP message from TSN network to the PTP ports in DS-TT(s) in Leader state within this PTP instance via PDU sessions terminating in this UPF that the UEs have established to the TSN network. The UPF/NW-TT also forwards the gPTP message to the PTP ports in NW-TT in Leader state within this PTP instance. All gPTP messages are transmitted on a QoS Flow that complies with the residence time upper bound requirement specified in IEEE Std 802.1AS [104]. NOTE 2: Leader and Follower terms in this specification maps to Master and Slave terms respectively for (g)PTP time synchronization as specified in IEEE Std 802.1AS [104] and IEEE Std 1588 [126]. This terminology can require update depending on the IEEE 1588 WG response to SA WG2. NOTE 3: The sum of the UE-DS-TT residence time and the PDB of the QoS Flow needs to be lower than the residence time upper bound requirement for a time-aware system specified in IEEE Std 802.1AS [104] in the following cases: a) If the PTP port in DS-TT is in Follower state and a PTP port in the NW-TT is in Leader state; or b) a PTP port in DS-TT is in Leader state and a PTP port in NW-TT is in Follower state. NOTE 4: If the PTP port in DS-TT is in a Follower state, and a PTP port in another DS-TT is in Leader state, then the sum of the residence time for these two DS-TT ports and the PDB of the QoS flow of the two PDU Sessions needs to be lower than the residence time upper bound requirement for a time-aware system specified in IEEE Std 802.1AS [104]. A UE receives the gPTP messages and forwards them to the DS-TT. The DS-TT then creates egress timestamping (TSe) for the gPTP event (Sync) messages for external TSN working domains. The difference between TSi and TSe is considered as the calculated residence time spent within the 5G system for this gPTP message expressed in 5GS time. The DS-TT then uses the rateRatio contained inside the gPTP message payload (carried within Sync message for one-step operation or Follow_up message for two-step operation) to convert the residence time spent within the 5GS in TSN GM time and modifies the payload of the gPTP message that it sends towards the downstream TSN node (gPTP entity connected to DS-TT) as follows: - Adds the calculated residence time expressed in TSN GM time to the correction field. - Removes Suffix field that contains TSi. If the ingress DS-TT has indicated support of the IEEE Std 802.1AS [104] PTP profile as described in clause K.2.1 and the network has configured a PTP instance with the IEEE Std 802.1AS [104] PTP profile for the ingress DS-TT, the ingress DS-TT performs the following operations for received UL gPTP messages for the PTP instance: - Adds the link delay from the upstream TSN node (gPTP entity connected to DS-TT) in TSN GM time to the correction field. - Replaces the cumulative rateRatio received from the upstream TSN node (gPTP entity connected to DS-TT) with the new cumulative rateRatio. - Adds TSi in the Suffix field of the gPTP packet. The UE transparently forwards the gPTP message from DS-TT to the UPF/NW-TT. If the ingress DS-TT port is in Passive state, the UPF/NW-TT discards the gPTP messages. If the ingress DS-TT port is in Follower state, the UPF/NW-TT forwards the gPTP messages as follows: - In the case of synchronizing end stations behind NW-TT, the egress port is in UPF/NW-TT. For the received UL gPTP messages, the egress UPF/NW-TT performs the following actions: - Adds the calculated residence time expressed in TSN GM to the correction field. - Removes Suffix field that contains TSi. - In the case of synchronizing TSN end stations behind DS-TT, the egress TT is DS-TT of the other UE, and the UPF/NW-TT uses the port number of the ingress DS-TT, and domainNumber and sdoId in the received gPTP message to assign the gPTP message to a PTP instance in the NW-TT. If the NW-TT does not have a matching PTP instance, the UPF/NW-TT discards the message. The UPF/NW-TT then forwards the received UL gPTP message to the PTP ports in DS-TT(s) in Leader state within this PTP instance. The egress DS-TT performs same actions as egress UPF/NW-TT in previous case. 5.27.1.2.2.2 Distribution of PTP Sync and Follow_Up messages This clause applies if DS-TT and NW-TT support distribution of PTP Sync and Follow_Up messages. PTP support by DS-TT and NW-TT may be determined as described in clause K.2.1. The mechanisms for distribution of PTP GM clock and time-stamping described in this clause are according to IEEE Std 1588 [126] for Transparent clock and for the case of Boundary clock when the GM is external, where the originTimestamp (or preciseOriginTimestamp) is not updated by the 5GS as described by the exemption in clause 5.27.1.1. If the 5GS acts as the GM with a PTP instance type Boundary clock, then the 5GS updates the originTimestamp (or preciseOriginTimestamp in case of two-step operation) with the 5GS internal clock, as described in clause 5.27.1.7. NOTE 1: This means externally-observable behaviour of the PTP instance in 5GS needs to comply with IEEE Std 1588 [126]. Upon reception of a PTP event message from the upstream PTP instance, the ingress TT (i.e. NW-TT or DS-TT) makes an ingress timestamping (TSi) for each PTP event (i.e. Sync) message. The PTP port in the ingress TT measures the link delay from the upstream PTP instance as described in clause H.4. The PTP port in the ingress TT modifies the PTP message payload (carried within Sync message for one-step operation or Follow_Up message for two-step operation) as follows: - (if the PTP port in the ingress TT has measured the link delay) Adds the measured link delay from the upstream PTP instance in PTP GM time to the correction field. - (if the PTP port in the ingress TT has measured the link delay and rateRatio is used) Replaces the cumulative rateRatio received from the upstream PTP instance with the new cumulative rateRatio. - Adds TSi in the Suffix field of the PTP message as described in clause H.2. NOTE 2: If the 5GS is configured to use the Cumulative frequency transfer method for synchronizing clocks as described in clause 16.10 in IEEE Std 1588 [126], i.e. when the cumulative rateRatio is measured, then the PTP port in the ingress TT uses the cumulative rateRatio received inside the PTP message payload (carried within Sync message for one-step operation or Follow_Up message for two-step operation) to correct the measured link delay to be expressed in PTP GM time as specified in IEEE Std 1588 [126]. The PTP port in the ingress TT then calculates the new cumulative rateRatio (i.e. the cumulative rateRatio of the 5GS) as specified in IEEE Std 1588 [126]. NOTE 3: If 5GS acts as an end-to-end Transparent Clock, since the end-to-end Transparent Clock does not support peer-to-peer delay mechanism, the residence time can be calculated with the residence time spent within the 5GS in 5G GM time and if needed, with a correction factor, for instance, as specified in Equation (6) of clause 12.2.2 of IEEE Std 1588 [126], this gives a residence time expressed in PTP GM time that is used to update the correction field of the received PTP Sync or Follow_Up message. The PTP port in the ingress TT then forwards the PTP message to the UPF/NW-TT. The UPF/NW-TT further distributes the PTP message as follows: - If the 5GS is configured to operate as Boundary Clock as described in IEEE Std 1588 [126], the UPF/NW-TT uses the port number of the ingress DS-TT and domainNumber and sdoId in the received PTP message to assign the PTP message to a PTP instance in the NW-TT. If the NW-TT does not have a matching PTP instance, the UPF/NW-TT discards the message. The UPF/NW-TT then regenerates the Sync and Follow_Up (for two-step operation) messages based on the received Sync and Follow_Up messages for the PTP ports in Leader state in NW-TT and DS-TT(s) within this PTP instance. The NW-TT/UPF forwards the regenerated Sync and Follow_Up (for two-step operation) messages to the Leader ports in NW-TT and the PDU session(s) related to the Leader ports in the DS-TT(s) within this PTP instance. - If the 5GS is configured to operate as a Transparent Clock as described in IEEE Std 1588 [126], the UPF/NW-TT uses the port number of the ingress TT and domainNumber and sdoId in the received PTP message to assign the PTP message to a PTP instance in the NW-TT. If the NW-TT does not have a matching PTP instance, the UPF/NW-TT discards the message. The UPF/NW-TT then forwards the received Sync messages to PTP ports in DS-TT(s) within this PTP instance via corresponding PDU Sessions terminating to this UPF, and to NW-TT ports within this PTP instance, except toward the ingress PTP port in the ingress TT. NOTE 4: If 5GS acts as a Transparent Clock, the 5GS does not maintain the PTP port states; the ingress PTP messages received on a PTP Port are retransmitted on all other PTP Ports of the Transparent Clock subject to the rules of the underlying transport protocol. NOTE 5: Due to the exemption described in clause 5.27.1.1, when the PTP instance in 5GS is configured to operate as a Boundary Clock, the 5GS does not need to synchronize its Local PTP Clock to the external PTP grandmaster. The PTP instance in 5GS measures the link delay and residence time and communicates these in a correction field. The externally observable behaviour of 5GS still conforms to the specifications for a Boundary Clock as described in IEEE Std 1588 [126]. The PTP port in the egress TT then creates egress timestamping (TSe) for the PTP event (i.e. Sync) messages 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. The PTP port in the egress TT then uses the rateRatio contained inside the PTP message payload (if available, carried within Sync message for one-step operation or Follow_Up message for two-step operation) to convert the residence time spent within the 5GS in PTP GM time. The PTP port in the egress TT modifies the payload of the PTP message (Sync message for one-step operation or Follow_Up message for two-step operation) that it sends towards the downstream PTP instance as follows: - Adds the calculated residence time to the correction field. - Removes Suffix field of the PTP message that contains TSi. NOTE 6: If 5GS acts as an end-to-end Transparent Clock, since the end-to-end Transparent Clock does not support peer-to-peer delay mechanism, the residence time is calculated with the residence time spent within the 5GS in 5G GM time and, if needed, corrected for instance with the factor as specified in Equation (6) of clause 12.2.2 of IEEE Std 1588 [126] to get it expressed in PTP GM time. The residence time is used to update the correction field of the received PTP event (e.g. Sync or Follow_Up) message.