5.27 Enablers for Time Sensitive Communications and Time Synchronization

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.27.0 General

This clause describes 5G System features that can be used independently or in combination to enable time-sensitive communication and time synchronization:

– Delay-critical GBR;

– A hold and forward mechanism to schedule traffic as defined in IEEE Std 802.1Q-2018 [98] for Ethernet PDU Sessions in DS-TT and NW-TT (see clause 5.27.4) to de-jitter flows that have traversed the 5G System if the 5G System is to participate transparently as a bridge in a TSN network;

– TSC Assistance Information: describes TSC flow traffic characteristics as described in clause 5.27.2 that may be provided optionally for use by the gNB, to allow more efficiently schedule radio resources for periodic traffic and applies to PDU Session type Ethernet and IP.

– Time Synchronization: describes how 5GS can operate as a PTP Relay (IEEE Std 802.1AS [104]), as a Boundary Clock or as Transparent Clock (IEEE Std 1588 [126]) for PDU Session type Ethernet and IP.

The 5G System integration as a bridge in an IEEE 802.1 TSN network as described in clause 5.28 can make use of all features listed above.

To support any of the above features to enable time-sensitive communication and time synchronization, during the PDU Session establishment, the UE shall request to establish a PDU Session as an always-on PDU Session, and the PDU Sessions are established as Always-on PDU session as described in clause 5.6.13. In this release of the specification, to use any of the above features to enable time-sensitive communication and time synchronization:

– Home Routed PDU Sessions are not supported;

– PDU Sessions are supported only for SSC mode 1;

– Service continuity is not supported when the UE moves from 5GS to EPS .i.e. interworking with EPS is not supported for a PDU Session for time synchronization or TSC.

5.27.1 Time Synchronization

5.27.1.1 General

For supporting time synchronization service, the 5GS is configured to operate in one or multiple PTP instances and to operate in one of the following modes (if supported) for each PTP instance:

1) as time-aware system as described in IEEE Std 802.1AS [104],

2) as Boundary Clock as described in IEEE Std 1588 [126], provisioned by the profiles supported by this 3GPP specification including SMPTE Profile for Use of IEEE Std 1588 [126] Precision Time Protocol in Professional Broadcast Applications ST 2059-2:2015 [127];

NOTE 1: Via proper configuration of the IEEE Std 1588 [126] data set members, the 5G internal system clock can become the time source for the PTP grandmaster function for the connected networks in the case of mode 1 and mode 2.

NOTE 2: In some cases where the 5G internal system clock is the time source for the PTP grandmaster function for the connected networks, it might not be required for the UE to receive gPTP or PTP messages over user plane. The UE and DS-TT uses the 5G timing information and generates the necessary gPTP or PTP message for the end station, if needed (this is implementation specific).

3) as peer-to-peer Transparent Clock as described in IEEE Std 1588 [126], provisioned by the profiles supported by this 3GPP specification including SMPTE Profile for Use of IEEE Std 1588 Precision Time Protocol in Professional Broadcast Applications ST 2059-2:2015 [127]; or

4) as end-to-end Transparent Clock as described in IEEE Std 1588 [126], provisioned by the profiles supported by this 3GPP specification including SMPTE Profile for Use of IEEE Std 1588 Precision Time Protocol in Professional Broadcast Applications ST 2059-2:2015 [127].

NOTE 3: When the GM is external, the operation of 5GS as Boundary Clock assumes that profiles that are supported by the 5GS allows the exemption specified in clauses 9.5.9 and 9.5.10 of IEEE Std 1588 [126] where the originTimestamp (or preciseOriginTimestamp in case of two-step operation) is not required to be updated with the syncEventEgressTimestamp (and a Local PTP Clock locked to the external GM). As described in clause 5.27.1.2.2, only correctionField is updated with the 5GS residence time and link delay, in a similar operation as specified by IEEE Std 802.1AS [104].

The configuration of the time synchronization service in 5GS for option 1 by TSN AF and CNC is described in clause 5.28.3, and for options 1-4 by AF/NEF and TSCTSF in clause 5.27.1.8 and clause 5.28.3.

The 5GS shall be modelled as an IEEE Std 802.1AS [104] or IEEE Std 1588 [126] compliant entity based on the above configuration.

NOTE 4: This release of the specification does not support the PTP management mechanism or PTP management messages as described in clause 15 in IEEE Std 1588 [126].

The DS-TT and NW-TT at the edge of the 5G system may support the IEEE Std 802.1AS [104] or other IEEE Std 1588 [126] profiles’ operations respective to the configured mode of operation. The UE, gNB, UPF, NW-TT and DS- TTs are synchronized with the 5G GM (i.e. the 5G internal system clock) which shall serve to keep these network elements synchronized. The TTs located at the edge of 5G system fulfil some functions related to IEEE Std 802.1AS [104] and may fulfil some functions related to IEEE Std 1588 [126], e.g. (g)PTP support and timestamping. Figure 5.27.1-1 illustrates the 5G and PTP grandmaster (GM) clock distribution model via 5GS.

Figure 5.27.1-1: 5G system is modelled as PTP instance for supporting time synchronization

Figure 5.27.1-1 depicts the two synchronizations systems considered: the 5G Clock synchronization and the (g)PTP domain synchronization.

– 5G Access Stratum-based Time Distribution: Used for NG RAN synchronization and also distributed to the UE. The 5G Access Stratum-based Time Distribution over the radio interface towards the UE is specified in TS 38.331 [28]. This method may be used to either further distribute the 5G timing to devices connected to a UE (using implementation-specific means) or to support the operation of the (g)PTP-based time distribution method.

– (g)PTP-based Time Distribution: Provides timing among entities in a (g)PTP domain. This process follows the applicable profiles of IEEE Std 802.1AS [104] or IEEE Std 1588 [126]. This method relies on the 5G access stratum-based time distribution method to synchronize the UE/DS-TT and on the 5GS time synchronization to synchronize the gNB (which, in turn, may synchronize the DS-TT) and the NW-TT.

The gNB needs to be synchronized to the 5G GM clock.

The 5GS supports two methods for determining the grandmaster PTP Instance and the time-synchronization spanning tree.

– Method a), BMCA procedure.

– Method b), local configuration.

This is further described in clause 5.27.1.6.

5.27.1.2 Distribution of timing information

5.27.1.2.1 Distribution of 5G internal system clock

The 5G internal system clock shall be made available to all user plane nodes in the 5G system. The UPF and NW-TT may get the 5G internal system clock via the underlying PTP compatible transport network with mechanisms outside the scope of 3GPP. The 5G internal system clock shall be made available to UE with signalling of time information related to absolute timing of radio frames as described in TS 38.331 [28]. The 5G internal system clock shall be made available to DS-TT by the UE.

5.27.1.2.2 Distribution of grandmaster clock and time-stamping

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.

5.27.1.3 Support for multiple (g)PTP domains

This clause describes support for multiple domains for gPTP and PTP and for GM clocks connected to DS-TT and NW-TT and only applies if DS-TT and NW-TT support the related functionality. PTP support and support of gPTP for GM clocks connected to DS-TT by DS-TT and NW-TT may be determined as described in clause K.2.1.

Each (g)PTP domain sends its own (g)PTP messages. The (g)PTP message carries a specific PTP "domainNumber" that indicates the time domain they are referring to. The PTP port in ingress TT makes ingress timestamping (TSi) for the (g)PTP event messages of all domains and forwards the (g)PTP messages of all domains to the UPF/NW-TT that further distributes the (g)PTP messages to the egress TTs as specified in clause 5.27.1.2.2.

The PTP port in the egress TT receives the original PTP GM clock timing information and the corresponding TSi via (g)PTP messages for one or more (g)PTP domains. The PTP port in the egress TT then makes egress timestamping (TSe) for the (g)PTP event messages for every (g)PTP domain. Ingress and egress time stamping are based on the 5G system clock at NW-TT and DS-TT.

NOTE 1: An end-station can select PTP timing information of interest based on the "domainNumber" in the (g)PTP message.

The process described in clause 5.27.1.2.2 is thus repeated for each (g)PTP domain between a DS-TT and the NW-TT it is connected to.

NOTE 2: If all (g)PTP domains can be made synchronous and the synchronization can be provided by the 5G clock, the NW-TT or DS-TT(s) generates the (g)PTP event messages of all domains using 5G clock as described in clause 5.27.1.7.

NOTE 3: This Release of the specification supports multiple gPTP domains as defined in IEEE Std 802.1AS [104]. If a 5GS TSN bridge supports stream gates and/or transmission gates as defined in IEEE Std 802.1Q [98], then they operate based on a single given gPTP domain.

5.27.1.4 DS-TT and NW-TT Time Synchronization functionality

This clause describes the support of Time Synchronization functionality supported by the 5G System. Synchronization between UPF/NW-TT and NG-RAN is outside scope of 3GPP.

DS-TT and NW-TT may support the following PTP instance types:

– Boundary Clock as defined in IEEE Std 1588 [126] as described in clause 5.27.1.1;

– End-to-End Transparent Clock as defined in IEEE Std 1588 [126] as described in clause 5.27.1.1;

– Peer-to-Peer Transparent Clock as defined in IEEE Std 1588 [126] as described in clause 5.27.1.1;

– PTP Relay instance as defined in IEEE Std 802.1AS [104].

Editor’s note: Support for external networks operating with IEEE Std 1588-2008 [107] is for further study.

DS-TT and NW-TT may support the following transports for PTP:

– IPv4 as defined in IEEE Std 1588 [126] Annex C;

– IPv6 as defined in IEEE Std 1588 [126] Annex D;

IEEE Std 802.3 [131] (Ethernet) as defined in IEEE Std 1588 [126] Annex E.

For operation as a Boundary clock or as a Transparent Clock, DS-TT and NW-TT may support the following path and link delay measurement methods:

– Delay request-response mechanism as described in clause 11.3 of IEEE Std 1588 [126];

– Peer-to-peer delay mechanism as defined in clause 11.4 of IEEE Std 1588 [126].

DS-TT and NW-TT may support acting as a PTP grandmaster, i.e. may support generating (g)PTP Announce, Sync and Follow_Up messages. DS-TT and NW-TT supporting (g)PTP shall support one or more PTP profiles as described in clause 20.3 of IEEE Std 1588 [126], i.e.:

– Default PTP Profiles in IEEE Std 1588 [126], Annex I;

– IEEE Std 802.1AS [104] PTP profile for transport of timing as defined in IEEE Std 802.1AS [104] Annex F;

– SMPTE Profile for Use of IEEE Std 1588 [126] Precision Time Protocol in Professional Broadcast Applications ST 2059-2:2015 [127].

TSN AF and TSCTSF may determine the PTP functionalities supported by DS-TT and NW-TT and may configure PTP instances in DS-TT and NW-TT using port and user plane node management information exchange as described in Annex K, clause K.2.

NOTE: How the TSN AF or TSCTSF assigns NW-TT port(s) of one NW-TT to different PTP instances is up to implementation.

5.27.1.5 Detection of (g)PTP Sync and Announce timeouts

The procedure described in this clause is applicable when the PTP instance in 5GS is configured to operate as a time-aware system or as a Boundary Clock, and the PTP grandmaster is external to the 5GS, and the BMCA procedure (Method a) is used as described in clause 5.27.1.6.

The NW-TT processes Announce messages according to IEEE Std 1588 [126].

In particular, the NW-TT shall compute and maintain the time when the Announce and Sync timeout events occur for the PTP port in a Follower state. When the 5GS is configured to operate as a time-aware system, the NW-TT shall determine the Sync and Announce message interval for the PTP Port at the other end of the link to which the Follower PTP Port in 5GS is attached, as described in IEEE Std 802.1AS [104]. When the 5GS is configured to operate as a Boundary Clock, the NW-TT shall determine Announce interval based on the configuration of the Follower port in 5GS, as described in IEEE Std 1588 [126].

The configuration of PTP instances in DS-TT and NW-TT for Sync and Announce timeouts is described in clause K.2. Upon detection of the Sync or Announce timeout event, the NW-TT shall re-evaluate the DS-TT and NW-TT port states as described in clause 5.27.1.6.

5.27.1.6 Distribution of Announce messages and best master clock selection

The procedure described in this clause is applicable if DS-TT and NW-TT support operating as a Boundary Clock described in IEEE Std 1588 [126] or as a time-aware system (support of the IEEE 802.1AS [104] PTP profile) and when the PTP instance in 5GS is configured to operate as a time-aware system or as a Boundary Clock. Whether DS-TT/NW-TT support operating as a Boundary Clock or as a time-aware system may be determined as described in clause K.2.1.

The externally-observable behaviour of the Announce message handling by 5GS needs to comply with IEEE Std 802.1AS [104] or IEEE Std 1588 [126], respective to the configured mode of operation.

The DS-TT forwards the received Announce messages to NW-TT over User plane. The NW-TT port forwards the received Announce messages from N6 interface to NW-TT.

The NW-TT maintains the PTP port state for each DS-TT port and NW-TT port. The PTP port states may be determined by NW-TT either via:

– Method a), BMCA procedure.

– Method b), local configuration.

When Method b) is used, the following applies:

– When the PTP GM is external to the 5GS, for one of the NW-TT or DS-TT ports (per each PTP domain) the PTP port state is Follower and for all other NW-TT and DS-TT ports of the same PTP domain the PTP port state is set either to Passive or Leader (depending on implementation).

– When the 5GS is configured as a grandmaster for a (g)PTP domain for the connected networks, all NW-TT ports and DS-TT ports are set to Leader state for that (g)PTP domain.

The local configuration of PTP port states in DS-TT and NW-TT for Method b is described in clause K.2.

When the Method a) is used (PTP port states are determined by BMCA procedure), the NW-TT needs to process the received Announce messages (from NW-TT port(s) and over user plane from the DS-TT(s)) for BMCA procedure, determine port states within the 5GS, and maintain the Leader-Follower hierarchy.

The DS-TT maintains the Disabled, Initializing and Faulty (if applicable) state for the PTP ports in DS-TT. While in Disabled, Initializing or Faulty state, the port in the DS-TT discards any (g)PTP messages it may receive from the upstream PTP instance or from the NW-TT via user plane.

When the 5GS Clock is determined as a grandmaster for a (g)PTP domain, the Announce messages are distributed as described in clause 5.27.1.7.

When the grandmaster is external to the 5GS, the NW-TT regenerates the Announce messages based on the Announce messages received from Follower port in NW-TT or DS-TT for the Leader ports in NW-TT and DS-TT(s). The NW-TT/UPF forwards the regenerated Announce messages to the PDU session(s) related to the Leader ports in the DS-TT(s).

NOTE 1: The TSN AF or TSCTSF can use the portDS.portState in the "Time synchronization information for each DS-TT port" element in UMIC to read and get notified for the port state changes for the PTP ports in DS-TT(s), and the portDS.portState in PMIC to read and get notified for the port state changes for the PTP ports in NW-TT. Based on the change of the port states, TSN AF or TSCTSF can determine that an external Grandmaster PTP Instance is found to be used instead of the GM in 5GS, or the GM in 5GS is selected as the Grandmaster PTP Instance, and TSN AF or TSCTSF can disable or enable the (g)PTP grandmaster functionality in DS-TT(s), respectively.

NOTE 2: The TSN AF or TSCTSF can use the portDS.portState in PMIC to read and get notified for the port state changes for the PTP ports in DS-TT for the port state Disabled, Initializing or Faulty (if applicable). The TSCTSF or TSN AF can use the portDS.portEnable to indicate to the NW-TT that the DS-TT port is disabled. This avoids unnecessary (g)PTP traffic over User Plane to a DS-TT port in Disabled, Initializing or Faulty state.

5.27.1.7 Support for PTP grandmaster function in 5GS

The 5GS that is configured to operate as a time-aware system or Boundary Clock may support acting as a PTP grandmaster for a (g)PTP domain.

The configuration of PTP instances in DS-TT and NW-TT for PTP grandmaster function is described in clause K.2.

The following options may be supported (per DS-TT) for the 5GS to generate the Sync, Follow_Up and Announce messages for the Leader ports on the DS-TT:

a) NW-TT generates the Sync, Follow_Up and Announce messages on behalf of DS-TT (e.g. if DS-TT does not support this).

The NW-TT/UPF forwards the generated Sync, Follow_Up and Announce messages to the PDU session(s) related to the Leader ports on the DS-TT(s). The NW-TT timestamps the (g)PTP event message when the event message is sent to the PDU Session, and adds TSi corresponding to the timestamp to the Sync message and the OriginTimestamp corresponding to the timestamp to Sync message (if one-step operation is used) or PreciseOriginTimestamp corresponding to the timestamp to Follow_Up message (if two-step operation is used), and sets the cumulative rateRatio value with 1. The OriginTimestamp or PreciseOriginTimestamp shall be set by NW-TT/UPF to the 5GS internal clock.

When DS-TT(s) receive the Sync, Follow_Up messages, it modifies the payload of the Sync, Follow_Up message as described for the PTP port in the egress TT in clause 5.27.1.2.2.2.

b) DS-TT generates the Sync, Follow_Up and Announce messages in this DS-TT. The OriginTimestamp or PreciseOriginTimestamp shall be set by DS-TT to the 5GS internal clock.

In both options, the NW-TT generates the Sync, Follow_Up and Announce messages for the Leader ports on the NW-TT.

5.27.1.8 Exposure of Time Synchronization

5G System supports time synchronization service that can be activated and deactivated by AF. Exposure of time synchronization comprises the following capabilities:

– The AF may learn 5GS and/or UE availability and capabilities for time synchronization service.

– The AF controls activation and deactivation of the time synchronization service for the target UE(s).

The AF may use the service-specific parameters to control the time synchronization service for targeted UE(s). These parameters are specified in clause 4.15.9.3 and 4.15.9.4 of TS 23.502 [3] for (g)PTP-based and 5G access stratum-based time synchronization services, respectively.

The AF may subscribe for 5GS and/or UE availability and capabilities for time synchronization service. The AF indicates in the request the DNN, S-NSSAI, and in addition the AF may indicate a list of UE identities or group identity to limit the subscription only to corresponding UEs. If the AF does not indicate DNN, S-NSSAI, the NEF determines the DNN, S-NSSAI based on the AF Identifier.

The TSCTSF (directly or via NEF) exposes the 5GS and/or UE availability and capabilities for synchronization service to the AF as described in clause 4.15.9.2 of TS 23.502 [3]. The exposed information includes the list of user plane node identities, the list of UE identities and may include the supported capabilities for (g)PTP time synchronization service per user plane node and UE.

The AF request to control the (g)PTP time synchronization service is sent to the TSCTSF (directly or via NEF). The request is targeted to a set of AF-sessions that are associated with the exposure of UE availability and capabilities for synchronization service.

The AF may request to use a specific PTP instance type when requesting the (g)PTP-based time synchronization distribution method (IEEE Std 1588 [126] or IEEE Std 802.1AS [104] operation (i.e. as a Boundary Clock, peer-to-peer Transparent Clock, or end-to-end Transparent Clock or as a PTP relay instance)). The request to control the (g)PTP time synchronization service may contain other service parameters as specified in Table 4.15.9.3-1 in clause 4.15.9.3 of TS 23.502 [3].

The AF may request to use the 5G access stratum as a time synchronization distribution method. In this case, the time source is provided by the 5GS. 5G-AN provides the 5GS time to the UE via 3GPP radio access; UE/DS-TT may provide 5G access stratum timing information to end stations using implementation specific means. The request to control the 5G access stratum time distribution (including the parameters such AF requests may contain) is described in clause 4.15.9.4 of TS 23.502 [3].

The AF or NEF selects the TSCTSF as specified in clause 6.3.24.

The AF request may include a time synchronization error budget (see also clause 5.27.1.9). The time synchronization error budget defines an upper bound for time synchronization errors introduced by 5GS.

The AF uses the procedure for configuring the (g)PTP instance in 5GS as described in clause 4.15.9.3 of TS 23.502 [3] and uses the procedure for providing the 5G access stratum time distribution as described in clause 4.15.9.4 of TS 23.502 [3] for the UEs.

The TSCTSF uses the Time Synchronization parameters (Table 4.15.9.3-1 in TS 23.502 [3]) as received from the AF (directly or via NEF) to control the (g)PTP time synchronization service. When IEEE Std 1588 [126] or IEEE Std 802.1AS [104] operation have been selected, the TSCTSF determines the necessary (g)PTP parameters to activate and control the service in DS-TT(s) and NW-TTs. For this purpose, the TSCTSF uses the PMIC or UMIC to manage the IEEE Std 1588 [126] or IEEE Std 802.1AS [104] operation in the DS-TT(s) or NW-TTs, respectively (see clause 5.27.1.4).

The TSCTSF uses the Time Synchronization parameters (Table 4.15.9.4-1) as received from the AF (directly or via NEF) to control the 5G access stratum time synchronization distribution as described in clause 4.15.9.4 of TS 23.502 [3].

For handling (g)PTP traffic, the PCF, according to PCC rule authorization, chooses a 5QI and dynamically set the PDB and/or MDBV according to requirements for (g)PTP protocol. The PCF provides the SMF with a PCC rule generated based on the AF request to control the (g)PTP time synchronization service. The SMF may take the information in the PCC rule to modify a PDU Session to create or modify or release a QoS Flow for transmitting the (g)PTP messages. The PCF acknowledges the policy request to the TSCTSF. The TSCTSF may report the result of the time synchronization request to the AF (directly or via NEF).

The AF may provide a temporal validity condition to the TSCTSF (directly or via NEF) when the AF activates the time synchronization service. Temporal validity condition contains the start-time and stop-time (in absolute time value) attributes that describe the time period when the time synchronization service is active for the targeted AF sessions. The TSCTSF manages the temporal validity condition as described in clauses 4.15.9.3 and 4.15.9.4 of TS 23.502 [3].

5.27.1.9 Support for derivation of Uu time synchronization error budget

The AF may request a specific time synchronization error budget when requesting a time synchronization service employing the (g)PTP-based or 5G access stratum-based time distribution method. If the AF includes a time synchronization error budget in its request, the TSCTSF uses it to derive an error budget available for the NG-RAN to provide the 5G access stratum time via the Uu interface to each targeted UE (referred to as Uu time synchronization error budget hereafter).

To derive the Uu time synchronization error budget for each targeted UE, the TSCTSF takes the following into account:

– selected time synchronization distribution method ( i.e.5G access stratum-based time distribution or (g)PTP-based time distribution);

– in the case of the (g)PTP-based time distribution:

– whether 5GS operates as a boundary clock and acts as a GM;

– whether a clock connected to the DS-TT/NW-TT acts as a GM;

– PTP port states;

– a CN part and a Device part of the time synchronization error budget (both parts may be predefined at the TSCTSF, or calculated by the 5GS using the implementation-specific means).

If the AF does not include a time synchronization error budget, the TSCTSF uses a preconfigured time synchronization error budget to derive the Uu time synchronization error budget. TheTSCTSF provides a 5G access stratum time distribution indication and the derived Uu time synchronization error budget to NG-RAN as described in clause 4.15.9.4 of TS 23.502 [3]. Based on this, NG-RAN provides the 5G access stratum time to the UE according to the Uu interface time synchronization error budget as provided by the TSCTSF (if supported by UE and NG-RAN). During Handover, Service Request, mobility registration and AM policy modification procedure, the AMF may provide the 5G access stratum time distribution indication and the Uu time synchronization error budget to NG-RAN as described in clause 4.15.9.4 of TS 23.502 [3], if needed.

NOTE: This release of the specification assumes that deployments ensure that the targeted UEs and the NG-RAN nodes serving those UEs support Rel-17 propagation delay compensation as defined in TS 38.300 [27].

5.27.1.10 Support for coverage area filters for time synchronization service

This feature enables the AF to request time synchronization service for a UE or a group of UEs in a specific geographical area (so called coverage area). The requested coverage area contains a list of Tracking Area (TA) or a geographical area (e.g. a civic address or shapes that the NEF transforms to list of TAs based on pre-configuration).

The spatial validity condition is resolved at the TSCTSF. In order to do that, the TSCTSF discovers the AMF(s) serving the list of TA(s) that comprise the spatial validity using the NRF and subscribes to the discovered AMF(s) to receive notifications about presence of the UE in an Area of Interest events (as described in clause 5.3.4.4 of TS 23.501 [2]). An Area of Interest (AoI) for each AMF is represented by a list of TA(s), wherein the Area of Interest is identical to the requested coverage area, or the Area of Interest is a TA.

Based on the outcome provided by the AMF about the UE’s presence in the AoI, the TSCTSF determines if the time synchronization service is activated or deactivated.

For access stratum distribution activation/deactivation, the TSCTSF will enable/disable access stratum time distribution to the UE at the serving NG-RAN node reusing the procedures in clause 4.15.9.4 of TS 23.502 [3]. For (g)PTP distribution activation/deactivation, the TSCTSF will modify the PTP instance configuration by means of sending a PMIC to the impacted UE/DS-TTs and UMIC to the impacted UPF/NW-TT, as described in clause K.2.2 of TS 23.501 [2].

If the time synchronization service is modified based on the reports of UE presence in the Area of Interest, the TSCTSF informs the AF for the impacted UE(s) by indicating the PTP port state for the related DS-TT PTP port (in the case of (g)PTP based time distribution) or notifying the AF with the indication of 5G access status time distribution status (enabled or disabled, for ASTI based time distribution).

In order to track the UE moving in and out of Time Synchronization coverage area at a TA granularity, the Registration Area (RA) shall only include TAs either inside or outside of the Requested Coverage Area the AF requested for Time Synchronization. This ensures the UE performs Registration update with the network when the UE moves in and out of Requested Coverage Area.

5.27.1.11 Controlling time synchronization service based on the Subscription

The distribution of timing information, 5G access stratum-based time distribution and (g)PTP-based time distribution, for a UE may be controlled based on subscription data stored in the UDM. The (g)PTP-based or 5G access stratum-based time synchronization service may be provided to a UE based on the UE’s subscription which is specified in the TS 23.502 [3] clause 5.2.3.3.1.

The Access and Mobility Subscription data include for the control of 5G access stratum-based time distribution the following information:

– the Access Stratum Time Synchronization Service Authorization, which indicates whether the UE should be provisioned with 5G system internal clock timing information over access stratum as specified in TS 38.331 [28].

– optionally, the Uu time synchronization error budget.

– optionally, one or more periods of start and stop times defining the times when the UE should be provisioned with 5G system internal clock timing information.

– optionally, a Time Synchronization Coverage Area comprising a list of TAs where the UE shall be provisioned with 5G system internal clock timing information.

During the Registration procedure, the AMF retrieves the subscription from UDM. If the AMF receives 5G access stratum-based time synchronization service subscription for the given UE, the AMF controls the 5G access stratum-based time distribution:

– If the 5G access stratum-based time synchronization service is allowed for the UE, the AMF provides the 5G access stratum time distribution indication to the NG-RAN so that it can provide 5G timing information to the UE.

– The AMF may provide a Uu time synchronization error budget to the NG-RAN (as described in clause 5.27.1.9). If the UE’s subscription contains a Uu time synchronization error budget, then AMF sends it to NG-RAN. Otherwise, the AMF uses the pre-configured Uu time synchronization error budget and sends it to NG-RAN.

– If the UE’s subscription contains Coverage Area (defined as a list of TAs), the AMF configures the NG-RAN to provide the 5G timing information to UE only when the UE is in the Coverage Area. In order to track the UE moving in and out of Time Synchronization Coverage Area, the Registration Area (RA) shall only include TAs either inside or outside of the subscribed Coverage Area.

NOTE: This ensures the UE performs Registration update with the network when the UE moves in and out of Requested Coverage Area.

Editor’s note: How to ensure that the Time Synchronization Coverage Area and the Registration Area consist of the same is FFS.

– If the AMF receives the start and stop times, then the AMF enables and disables the 5G access stratum time distribution indication to the NG-RAN according to the expiry of start and stop times if the UE is in CM_Connected state. If the UE is in CM_Idle state when a Start time condition is met, the AMF pages the UE and provides the 5G access stratum time distribution indication to NG-RAN as part of the subsequent service request procedure initiated by the UE in the response to the paging.

– The TSCTSF retrieves the Time Synchronization Subscription data from the UDM when the TSCTSF receives an AF request for 5G access stratum-based time synchronization service. According to the "AF request Authorization" in the Time Synchronization Subscription data, the TSCTSF determines whether the UE is authorized for an AF-requested time synchronization service. If the UE is authorized, the TSCTSF proceeds as specified in clause 5.27.1.8 and TS 23.502 [3].

The Time Synchronization Subscription data is the subscription data for the control of (g)PTP-based time distribution and 5G access stratum-based time distribution and includes the following information:

– the "AF request Authorization", indicating whether the UE is authorized for an AF-requested 5G access stratum-based time distribution and (g)PTP-based time distribution services. The indication is provided separately for each service:

– "allowed" or "not allowed" for (g)PTP based time synchronization service (per DNN/S-NSSAI and UE identity),

– "allowed" or "not allowed" for ASTI based time synchronization services (per UE identity).

– optionally, a list of TA(s) which specifies an area (a so called Time Synchronization Coverage Area) in which an AF may request time synchronization services.

– one or more Subscribed time synchronization service ID(s), each containing the DNN/S-NSSAI and a reference to a PTP instance configuration pre-configured at the TSCTSF (e.g. PTP profile, PTP domain, etc.):

– optionally, for each PTP instance configuration, one or more periods of start and stop times defining active times of time synchronization service for the PTP instance.

– optionally, for each PTP instance configuration, a Time Synchronization Coverage Area defining a list of TAs where the (g)PTP-based time synchronization is available for the UEs in the PTP instance.

– optionally, Uu time synchronization error budget.

The TSCTSF retrieves the Time Synchronization Subscription data from UDM. The TSCTSF controls the Time Synchronization Service. If the UE subscription includes (g)PTP-based time synchronization service subscription:

– The TSCTSF retrieves the Time Synchronization Subscription data from the UDM when the TSCTSF receives an AF request for the time synchronization service (either ASTI or (g)PTP).

– According to the "AF request Authorization" in the UE’s subscription data, the TSCTSF determines whether the UE is authorized for an AF-requested time synchronization service and, if the UE’s subscription data contains a Time Synchronization Coverage Area (i.e., a list of TA(s) defining the restricted area for AF request), whether the UE is in the allowed area. If the AF request is authorized and the corresponding UE is in the allowed area, the TSCTSF proceeds as specified in clause 5.27.1.8 and TS 23.502 [3].

– The TSCTSF retrieves the Time Synchronization Subscription data from the UDM when it receives notification from the PCF that a UE has established a PDU Session that is potentially impacted by (g)PTP-based time synchronization service.

– The TSCTSF retrieves the PTP instance configurations referenced from the "Subscribed time synchronization service ID(s)". The PTP instance configurations are stored locally in the TSCTSF. The TSCTSF determines if one or more of the PTP instance configurations match with the DNN/S-NSSAI of the given PDU Session. If no PTP instance exists for the given PTP instance configuration, the TSCTSF initializes the PTP instance in 5GS as described in clause K.2.2 of TS 23.501 [2].

– The TSCTSF configures a PTP port in DS-TT and adds it to the corresponding PTP instance in NW-TT as described in clause K.2.2 of TS 23.501 [2].

– If the PTP instance configuration referenced by the Time Synchronization Subscription data for the UE contains start and stop times, the TSCTSF, upon expiry of start time, creates the PTP instance and adds the PTP port in DS-TT to the PTP instance. Upon expiry of stop time, if this is the last period of start and stop times in the PTP instance configuration, the TSCTSF deletes the PTP instance, otherwise the TSCTSF temporarily disables the PTP instance.

– If the PTP instance configuration referenced by the Time Synchronization Subscription data for the UE contains a Time Synchronization Coverage Area, the TSCTSF subscribes to UE’s Presence in Area(s) of Interest corresponding to the Time Synchronization Coverage Area at the discovered AMF(s). When the TSCTSF determines that the UE has moved inside or outside of the Time Synchronization Coverage Area, the TSCTSF adds or temporarily removes the PTP port in DS-TT from the corresponding PTP instance.

5.27.1a Periodic deterministic communication

This clause describes 5G System features that allow support of periodic deterministic communication where the traffic characteristics are known a-priori, and a schedule for transmission from the UE to a downstream node, or from the UPF to an upstream node is provided via external protocols outside the scope of 3GPP (e.g. IEEE 802.1 TSN).

The features include the following:

– Providing TSC Assistance Information (TSCAI) that describe TSC flow traffic characteristics (as described in clause 5.27.2) at the gNB ingress and the egress of the UE for traffic in downlink and uplink direction, respectively;

– Support for hold & forward buffering mechanism (see clause 5.27.4) in DS-TT and NW-TT to de-jitter flows that have traversed the 5G System.

5.27.2 TSC Assistance Information (TSCAI) and TSC Assistance Container (TSCAC)

5.27.2.1 General

TSC Assistance Information (TSCAI) is defined in Table 5.27.2-1 and describes TSC traffic characteristics for use in the 5G System. TSCAI may be used by the 5G-AN, if provided by SMF. The knowledge of TSC traffic pattern is useful for 5G-AN as it allows more efficiently scheduling of QoS Flows that have a periodic, deterministic traffic characteristics either via Configured Grants, Semi-Persistent Scheduling or with Dynamic Grants.

The TSCTSF determines the TSC Assistance Container (defined in Table 5.27.2-2) based on information provided by an AF/NEF as described in clause 5.27.2.3 and provides it to the PCF for IP type and Ethernet type PDU Sessions. In the case of integration with IEEE TSN network, the TSN AF determines TSC Assistance Container as described in clause 5.27.2.2 and provides it to the PCF for Ethernet PDU Sessions. The PCF receives the TSC Assistance Container from the TSCTSF or the TSN AF and forwards it to the SMF as part of PCC rule as described in clause 6.1.3.23a of TS 23.503 [45].

The SMF binds a PCC rule with a TSC Assistance Container to a QoS Flow as described in clause 6.1.3.2.4 of TS 23.503 [45]. The SMF uses the TSC Assistance Container to derive the TSCAI for that QoS Flow and sends the derived TSCAI to the NG-RAN. The Periodicity, Burst Arrival Time, and Survival Time components of the TSCAI are specified by the SMF with respect to the 5G clock. The SMF is responsible for mapping the Burst Arrival Time and Periodicity from an external clock (when available) to the 5G clock based on the time offset and cumulative rateRatio (when available) between the external clock time and 5GS time as measured and reported by the UPF. The SMF determines the TSCAI as described in clause 5.27.2.4.

A Survival Time, which indicates the time period an application can survive without any data burst, may be provided by TSN AF/AF either in terms of maximum number of messages (message is equivalent to all packets of a data burst) or in terms of time units. Only a single data burst is expected within a single time period referred to as the periodicity.

The SMF may send an update of the TSCAI to the NG-RAN as defined in clauses 4.3.3.2, 4.9.1.2.2 and 4.9.1.3.2 of TS 23.502 [3].

Table 5.27.2-1: TSC Assistance Information (TSCAI)

Assistance Information	Description
Flow Direction	The direction of the TSC flow (uplink or downlink).
Periodicity	It refers to the time period between start of two data bursts.
Burst Arrival Time (optional)	The latest possible time when the first packet of the data burst arrives at either the ingress of the RAN (downlink flow direction) or the egress of the UE (uplink flow direction).
Survival Time (optional)	Survival Time, as defined in TS 22.261 [2], refers to the time period an application can survive without any data burst.
Burst Arrival Time Window (BAT Window) (optional) (NOTE 1) (NOTE 2)	Indicates the acceptable earliest and latest arrival time of the first packet of the data burst at either the ingress of the RAN (downlink flow direction) or the egress of the UE (uplink flow direction).
Capability for BAT adaptation (optional) (NOTE 1)	Indicates that the AF will adjust the burst sending time according to the network provided Burst Arrival Time offset (see clause 5.27.2.5).
NOTE 1: Only one of the parameters (BAT Window or Capability for BAT adaptation) can be provided. NOTE 2: The parameter will only be provided together with Burst Arrival Time.

Table 5.27.2-2: TSC Assistance Container (TSCAC)

Assistance Information	Description
Flow Direction	The direction of the TSC flow (uplink or downlink).
Periodicity	It refers to the time period between start of two data bursts.
Burst Arrival Time (optional)	The time when the first packet of the data burst arrives at the ingress port of 5GS for a given flow direction (DS-TT for uplink, NW-TT for downlink).
Survival Time (optional)	It refers to the time period an application can survive without any data burst, as defined in TS 22.261 [2].
Time Domain (optional)	The (g)PTP domain of the TSC flow.
Burst Arrival Time Window (BAT Window) (optional) (NOTE 1) (NOTE 2)	Indicates the acceptable earliest and latest arrival time of the first packet the data burst at the ingress port of 5GS for a given flow direction (DS-TT for uplink, NW-TT for downlink).
Capability for BAT adaptation (optional) (NOTE 1)	It indicates that the AF will adjust the burst sending time according to the network provided Burst Arrival Time offset (see clause 5.27.2.5).
NOTE 1: Only one of the parameters (BAT Window or Capability for BAT adaptation) can be provided. NOTE 2: The parameter will only be provided together with Burst Arrival Time.

5.27.2.2 TSC Assistance Container determination based on PSFP

In the case of integration with IEEE TSN network, the TSN AF determines a TSC Assistance Container (defined in Table 5.27.2-2) and provides it to the PCF. The determination of TSC Assistance Container based on Per-Stream Filtering and Policing (PSFP) information applies only to Ethernet type PDU Sessions.

NOTE 1: This clause assumes that PSFP information as defined in IEEE Std 802.1Q [98] and Table 5.28.3.1-1is provided by CNC. PSFP information may be provided by CNC if TSN AF has declared PSFP support to CNC. TSN AF indicates the support for PSFP to CNC only if all the DS-TT and NW-TT ports of the 5GS Bridge have indicated support of PSFP. Means to derive the TSC Assistance Container if PSFP is not supported by 5GS and/or the CNC are beyond the scope of this specification.

The TSN AF may be able to identify the ingress port and thereby the PDU Session as described in clause 5.28.2.

The TSN AF interfaces towards the CNC for the PSFP (IEEE Std 802.1Q [98]) managed objects that correspond to the PSFP functionality implemented by the DS-TT and the NW-TT. Thus, when PSFP information is provided by the CNC, the TSN AF may extract relevant parameters from the PSFP configuration. The TSN AF calculates traffic pattern parameters (such as burst arrival time with reference to the ingress port and periodicity). TSN AF also obtains the flow direction as specified in clause 5.28.2. Survival Time may be pre-configured in TSN AF.

TSN AF may enable aggregation of TSN streams if the TSN streams belong to the same traffic class, terminate in the same egress port and have the same periodicity and compatible Burst arrival time. When Survival Time information is provided for a TSN stream, then it should not be aggregated with other TSN streams into a single QoS Flow, or if they are aggregated, then the Survival Time parameter shall not be provided. One set of parameters and one TSC Assistance Container are created by the TSN AF for multiple TSN streams to enable aggregation of TSN streams to the same QoS Flow.

Annex I describe how the traffic pattern information is determined.

NOTE 2: Further details of aggregation of TSN streams (including determination of burst arrival times that are compatible so that TSN streams can be aggregated) are left for implementation.

NOTE 3: In order for the TSN AF to get Burst Arrival Time, Periodicity on a per TSN stream basis, support for IEEE Std 802.1Q [98] (as stated in clause 4.4.8.2) Per-Stream Filtering and Policing (PSFP) with stream gate operation is a prerequisite.

For a UE-UE TSC stream, the (TSN) AF divides the stream into one uplink stream and one or more downlink streams as defined in clause 5.28.2. The TSN AF binds the uplink and downlink streams to the PDU Sessions, and provides the streams on AF Session basis to the PCF(s). The TSN AF calculates traffic pattern parameters for the UL and the DL stream using the PSFP configuration (if provided) respectively:

– For the uplink stream, the Flow Direction is set to uplink and traffic pattern parameters (such as burst arrival time with reference to the ingress port and periodicity) is determined as described in Annex I.

– For downlink stream, the Flow Direction is set to downlink, the burst arrival time is set to sum of burst arrival time of the UL stream and 5GS Bridge delay of PDU Session carrying the UL stream, and the periodicity is determined as described in Annex I.

5.27.2.3 TSC Assistance Container determination by TSCTSF

The TSCTSF constructs TSC Assistance Container (defined in Table 5.27.2-2) based on information provided (directly or via NEF) by the AF for IP or Ethernet type PDU Sessions.

The AF may provide Flow Direction, Burst Arrival Time (optional) at the UE/DS-TT (uplink) or UPF/NW-TT (downlink), Maximum Burst Size, Periodicity, Survival Time (optional), and a Time Domain (optional) to the TSCTSF. If the AF is able to adjust the burst sending time, the AF may in addition provide a BAT Window or the Capability for BAT adaptation to the TSCTSF. Based on these parameters, the TSCTSF constructs a TSC Assistance Container and provides it to PCF. If the AF provides to the TSCTSF a Burst Arrival Time or Periodicity without corresponding Time Domain, the TSCTSF sets the Time Domain = "5GS" in the TSC Assistance Container.

NOTE: The Maximum Burst Size is signalled separately, i.e. it is not part of the TSC Assistance Container.

The AF provides these parameters to the NEF and the NEF forwards these parameters to the TSCTSF. The AF trusted by the operator provides these parameters to the TSCTSF directly.

The TSCTSF sends the TSC Assistance Container to the PCF as follows:

– The TSCTSF uses the UE IP address/DS-TT port MAC address to identify the PCF and N5 association related to the PDU Session of a UE/DS-TT.

5.27.2.4 TSCAI determination based on TSC Assistance Container

The SMF determines the TSCAI (defined in Table 5.27.2-1) for the QoS Flow based on the TSC Assistance Container of the PCC rule bound to the QoS Flow. This clause is applicable irrespective of whether the TSC Assistance Container is determined by the TSN AF or by the TSCTSF.

The Burst Arrival Time and Periodicity component of the TSCAI that the SMF sends to the 5G-AN are specified with respect to the 5G clock. The SMF is responsible for mapping the Burst Arrival Time and Periodicity in the TSC Assistance Container from an external clock to the 5G clock based on the time offset and cumulative rateRatio (when available) between external time and 5GS time as measured and reported by the UPF. The SMF may correct the TSCAI based on the UPF report for time offset and cumulative rateRatio between external PTP time and 5GS time as measured and reported by the UPF.

The TSCAI parameter determination in SMF is done as follows:

– For traffic in downlink direction, the SMF corrects the Burst Arrival Time in the TSC Assistance Container based on the latest received time offset measurement from the UPF and sets the TSCAI Burst Arrival Time as the sum of the corrected value and CN PDB as described in clause 5.7.3.4, representing the latest possible time when the first packet of the data burst arrives at the AN.

– For traffic in uplink direction, the SMF corrects the Burst Arrival Time in the TSC Assistance Container based on the latest received time offset measurement from the UPF and sets the TSCAI Burst Arrival Time as the sum of the corrected value and UE-DS-TT Residence Time, representing the latest possible time when the first packet of the data burst arrives at the egress of the UE. How the SMF corrects the Burst Arrival Time if the UE-DS-TT Residence Time has not been provided by the UE is up to SMF implementation.

– The SMF corrects the Periodicity in the TSC Assistance Container using the cumulative rateRatio if the cumulative rateRatio was previously received from the UPF and sets the TSCAI Periodicity as the corrected value. Otherwise, the SMF sets the received Periodicity in the TSCAI without any correction.

– The SMF sets the TSCAI Flow Direction as the Flow Direction in the TSC Assistance Container.

– If Survival Time is provided in terms of maximum number of messages, the SMF converts maximum number of messages into time units by multiplying its value by the TSCAI Periodicity, and sets the TSCAI Survival Time to the calculated value. If Survival Time is provided in time units, the SMF corrects the Survival Time using the cumulative rateRatio if the cumulative rateRatio was previously received from the UPF and sets the TSCAI Survival Time to the corrected value. Otherwise, SMF sets the TSCAI Survival Time without correction.

– If the TSC Assistance Container contains a BAT Window, the SMF sets and corrects the indicated earliest and latest possible arrival time of the first packet in the same way it is described for the correction of the Burst Arrival Time above.

– If the TSC Assistance Container contains a Capability for BAT adaptation, the SMF sets the Capability for BAT adaptation in the TSCAI.

Depending on whether the Time Domain is provided in the TSC Assistance container, SMF may perform the following:

– the SMF provisions the UPF/NW-TT to report the clock drifting between 5G clock and the external GM clock for the (g)PTP time domain number that is configured to the NW-TT.

– the SMF provisions the UPF/NW-TT to report the clock drifting between 5G clock and the external GM clock for the given Time Domain number.

The SMF uses the N4 Association Setup or Update procedures as described in clause 4.4.3 of TS 23.502 [3] to provision the UPF to report the clock drifting.

If the SMF has clock drift information for a Time Domain and if the Time Domain matches with the Time Domain in the TSC Assistance Container (i.e. clock drift between 5G timing and AF supplied Time Domain determined based on UPF reporting), or Time Domain information is not provided in the TSC Assistance Container, then the SMF may adjust the TSCAI information so that it reflects the 5GS Clock as described in clause 5.27.2.1.

If the SMF does not have synchronization information for a requested Time Domain in the TSC Assistance Container, or the Time Domain in the TSC Assistance Container is set to a value = "5GS", then the TSCAI information will be used without adjustment.

In the case of drift between external GM clock and 5G clock, the UPF updates the offset to SMF using the N4 Report Procedure as defined in clause 4.4.3.4 of TS 23.502 [3]. If the cumulative rateRatio is available and in the case of change of cumulative rateRatio between external PTP time and 5G time, the UPF updates the cumulative rateRatio to SMF using the N4 Report Procedure as defined in clause 4.4.3.4 of TS 23.502 [3]. The SMF may then trigger a PDU Session Modification as defined in clause 4.3.3 of TS 23.502 [3] in order to update the TSCAI to the NG-RAN without requiring AN or N1 specific signalling exchange with the UE.

NOTE 4: In order to prevent frequent updates from the UPF, the UPF sends the offset or the cumulative rateRatio only when the difference between the current measurement and the previously reported measurement is larger than a threshold as described in clause 4.4.3.4 of TS 23.502 [3].

5.27.2.5 RAN feedback for Burst Arrival Time offset

5.27.2.5.1 Overview

If the NG-RAN receives a TSCAI containing a BAT Window or the Capability for BAT adaptation for a QoS Flow, the NG-RAN can determine a BAT offset in order to align the arrival of the traffic bursts with the next expected transmission opportunity over the air interface in each direction (i.e. DL or UL). The BAT offset can take a positive or a negative values.

NG-RAN may support the following feedback mechanisms:

– Proactive RAN feedback for Burst Arrival Time adaptation: NG-RAN may provide a Burst Arrival Time offset as part of QoS flow establishment or modification as illustrated in clause 5.27.2.5.2;

– Reactive RAN feedback for Burst Arrival Time adaptation: NG-RAN may provide a Burst Arrival Time offset after QoS flow establishment as illustrated in clause 5.27.2.5.3.

5.27.2.5.2 Proactive RAN feedback for Burst Arrival Time adaptation with BAT

If the RAN receives a Burst Arrival Time and either the capability for BAT adaptation or a Burst Arrival Time Window in the TSCAI for a QoS Flow, the 5GS will perform the following actions:

– The NG-RAN can determine a BAT offset in order to align the expected arrival of the traffic bursts (as indicated in the BAT) with the time when the next transmission over the air interface in each direction (i.e. DL or UL) is expected. Alternatively, NG-RAN may choose to not send ‘BAT offset’ in response if AF provided BAT is acceptable by NG-RAN. If BAT window was included in TSCAI, then the BAT offset shall always be provided by NG-RAN and it shall be within the BAT Window. The BAT offset is calculated with reference to earliest arrival time of received BAT Window.

– The BAT offset is provided from NG-RAN to the SMF in the response to the QoS Flow establishment or modification request. The SMF provides the BAT offset to the PCF and the PCF notifies the AF as described in clause 6.1.3.23a of TS 23.503 [45].

NOTE: It is assumed that the feedback from RAN implies the RAN accepts the BAT offset.

– If interworking with a TSN network deployed in the transport network is supported, the SMF/CUC uses the periodicity and BAT offset accepted by the RAN to adjust the EarliestTransmitOffset and LatestTransmitOffset in the Talker/Listener Group in IEEE 801.Qcc [95] as described in clause 5.28a.2.

Editor’s note: Whether RAN may provide periodicity feedback is FFS.

5.27.2.5.2 Reactive RAN feedback

If the RAN receives the capability for BAT adaptation in the TSCAI and notification control is enabled for this QoS Flow, the 5GS will perform the following actions:

– If NG-RAN determines that the PDB of the QoS flow cannot be fulfilled in DL direction, then if supported, NG-RAN shall determine a BAT offset value which reduces the time between the arrival of the traffic bursts and the time of the next possible transmission over the air interface. NG-RAN shall not provide a BAT offset with the same value until the PDB of the QoS Flow can be fulfilled again.

NOTE: NG-RAN determines BAT offset value in reference to the current arrival time of the bursts experienced by RAN.

– The BAT offset is provided from NG-RAN to the SMF when sending the notification towards the SMF that the "GFBR can no longer be guaranteed" described in clause 5.7.2.4. The SMF provides the BAT offset to the PCF and the PCF provides the BAT offset to the AF as part of notifying the AF as described in clause 6.1.3.23a of TS 23.503 [45]

Editor’s note: UL BAT adaptation is subject to feedback from RAN WG2.

5.27.3 Support for TSC QoS Flows

TSC QoS Flows use a Delay-critical GBR resource type and TSC Assistance Information. TSC QoS Flows may use standardized 5QIs, pre-configured 5QIs or dynamically assigned 5QI values (which requires signalling of QoS characteristics as part of the QoS profile) as specified in clause 5.7.2. For each instance of Periodicity, within each Period (defined by periodicity value), TSC QoS Flows are required to transmit only one burst of maximum size MDBV within the 5G-AN PDB. Known QoS Flow traffic characteristics provided in the TSCAI may be used to optimize scheduling in the 5GS.

The following is applicable for the QoS profile defined for TSC QoS Flows:

1. The TSC Burst Size may be used to set the MDBV as follows:

The maximum TSC Burst Size is considered as the largest amount of data within a time period that is equal to the value of 5G-AN PDB of the 5QI. The maximum value of TSC Burst Size should be mapped to a 5QI with MDBV that is equal or higher. When integration with IEEE TSN applies, this 5QI also shall have a PDB value that satisfies the bridge delay capabilities (see clause 5.27.5 for more details) reported for the corresponding traffic class. For TSC QoS Flows, the Maximum Burst Size of the aggregated TSC streams to be allocated to this QoS Flow can be similarly mapped to a 5QI with MDBV value that is equal or higher.

2. The PDB is explicitly divided into 5G-AN PDB and CN PDB as described in clause 5.7.3.4. Separate delay budgets are necessary for calculation of expected packet transmit times on 5G System interfaces. For the TSC QoS Flow, the5G-AN PDB is set to value of 5QI PDB minus the CN PDB as described in clause 5.7.3.4. The CN PDB may be static value or dynamic value and is up to the implementation of 5GS bridge.

3. When integration with IEEE TSN applies, the Maximum Flow Bitrate calculated by the TSN AF as per Annex I.1 may be used to set GBR. In this case, MBR is set equal to GBR.

4. ARP is set to a pre-configured value.

5. 5QI value is derived using QoS mapping tables and TSN QoS information as described in clause 5.28.4 in the case of integration with IEEE TSN network, or using QoS Reference parameters and Requested PDB, Burst Size, Priority parameters as described in clause 4.15.6.6 or clause 4.15.6.6a of TS 23.502 [3] in the case of AF requested Time Sensitive Communication.

5.27.4 Hold and Forward Buffering mechanism

DS-TT ports and NW-TT ports support a hold and forward mechanism to schedule traffic as defined in IEEE Std 802.1Q-2018 [98] if 5GS is to participate transparently as a bridge in a TSN network. That is, the hold and forward buffering mechanism in this release of the specification provides externally observable behaviour identical to scheduled traffic with up to eight queues (clause 8.6.8.4 in IEEE Std 802.1Q-2018 [98]) and with protected windows (Annex Q.2 in IEEE Std 802.1Q-2018 [98]). Frames are only transmitted from a given buffer according to the open time interval of the corresponding transmission gate; otherwise, frames are hold back (which corresponds to a closed transmission gate). The protected windows scheme implies that only a single transmission gate is open at any single time. Thus, the Hold and Forward buffering mechanism allows PDB based 5GS QoS to be used for TSC traffic.

For Ethernet frames that contain a VLAN tag, DS-TT and NW-TT determine the priority based on the PCP value contained in the VLAN tag. For Ethernet frames that do not contain a VLAN tag, DS-TT and NW-TT apply a priority value of 0.

To achieve externally observable behaviour according to the protected windows scheme, 5GS provides AdminControlList, AdminBaseTime, AdminCycleTime and TickGranularity as defined in IEEE Std 802.1Q [98] on a per Ethernet port basis to DS-TT and NW-TT for the hold and forward buffering mechanism as described in clause 5.28.3.

NOTE: The details of how Hold and Forward buffering mechanism is provided by the DS-TT and NW-TT is up to implementation.

5.27.5 5G System Bridge delay

This clause applies if 5GS is integrated as a bridge into an IEEE TSN network.

In order for the 5G System to participate as a TSN bridge according to transmission gate schedules specified, the 5GS Bridge is required to provide Bridge Delays as defined in IEEE Std 802.1Qcc [95] for each port pair and traffic class of the 5GS bridge to an IEEE 802.1 TSN system. In order to determine 5GS Bridge Delays, the following components are needed:

1. UE-DS-TT Residence Time.

2. Per traffic class minimum and maximum delays between the UE and the UPF/NW-TT that terminates the N6 interface (including UPF and NW-TT residence times), independent of frame length that a given 5GS deployment supports. The per-traffic class delays between the UE and the UPF/NW-TT are pre-configured in the TSN AF (see clause 5.28.4).

The TSN AF calculates the 5GS independentDelayMin and independentDelayMax values for each port pair and for each traffic class using the above components. If the UE-DS-TT Residence Time has not been provided by the UE, then the TSN AF uses a locally configured minimum UE-DS-TT Residence Time for the calculation of independentDelayMin and a locally configured maximum UE-DS-TT Residence Time for the calculation of independentDelayMax.

The dependentDelayMin and dependentDelayMax for 5GS Bridge specify the time range for a single octet of an Ethernet frame to transfer from ingress to egress and include the time to receive and store each octet of the frame, which depends on the link speed of the ingress Port as per IEEE Std 802.1Qcc [95].

NOTE: Further details how TSN AF determines dependentDelayMin and dependentDelayMax are up to implementation.

Since residence times may vary among UEs and per traffic class delay between the UE and the UPF/NW-TT may vary among UPFs, the 5GS Bridge Delay is determined after the PDU Session Establishment for the corresponding UPF and the UE by the TSN AF. The TSN AF deduces the related port pair(s) from the port number of the DS-TT Ethernet port and port number of the NW-TT Ethernet port(s) of the same 5GS Bridge when the TSN AF receives the 5GS Bridge information for a newly established PDU Session and calculates the bridge delays per port pair. Additionally, TSN AF deduces the port pair(s) consisting of two DS-TT ports connecting to the same 5GS bridge and determines the 5GS bridge delay as sum of bridge delays related to PDU Sessions of two DS-TT ports.