This clause describes 5G System features that support TSC and allow the 5G System to be integrated transparently as a bridge in an IEEE TSN network.
During the PDU Session establishment, the UE shall request to establish a PDU Session as an always-on PDU Session, and the PDU Sessions used for TSC are established as Always-on PDU session as described in clause 5.6.13. In this release of the specification:
Home Routed PDU Sessions are not supported for TSC services;
TSC PDU Sessions are supported only with PDU Session type Ethernet and SSC mode 1;
Service continuity for TSC PDU Sessions is not supported when the UE moves from 5GS to EPS.
For supporting TSN time synchronization, the 5GS is integrated with the external network as a TSN bridge as described in clauses 4.4.8 and 5.28.1. It shall be modelled as an IEEE 802.1AS  compliant entity according to TS 22.104. For TSN Synchronization, the entire E2E 5G system can be considered as an IEEE 802.1AS  "time-aware system". Only the TSN Translators (TTs) at the edges of the 5G system need to support the IEEE 802.1AS  operations. 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 all functions related to IEEE 802.1AS , e.g. (g)PTP support, timestamping, Best Master Clock Algorithm (BMCA), rateRatio. Figure 5.27.1-1 illustrates the 5G and TSN clock distribution model via 5GS.
Figure 5.27.1-1 depicts the two synchronizations systems considered: the 5GS synchronization and the TSN domain synchronization, as well as the Master (M) and Slave (S) ports considered when the TSN GM is located at TSN working domain.
5GS synchronization: Used for NG RAN synchronization. 5G RAN synchronization is specified in TS 38.331.
TSN domain synchronization: Provides synchronization service to TSN network. This process follows IEEE 802.1AS .
The two synchronization processes can be considered independent from each other and the gNB only needs to be synchronized to the 5G GM clock.
To enable TSN synchronization, the 5GS calculates and adds the measured residence time between the TTs into the Correction Field (CF) of the synchronization packets of the TSN working domain.
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 signaling of time information related to absolute timing of radio frames as described in TS 38.331. The 5G internal system clock shall be made available to DS-TT by the UE.
The mechanisms for distribution of TSN clock and time-stamping described in this clause are according to IEEE 802.1AS .
Upon reception of a downlink gPTP message 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) expressed in TSN GM time as specified in IEEE 802.1AS . NW-TT then calculates the new cumulative rateRatio (i.e. the cumulative rateRatio of the 5GS) as specified in IEEE 802.1AS  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 Annex H.
UPF then forwards the gPTP message from TSN network to the UEs via all PDU sessions terminating in this UPF that the UEs have established to the TSN network. All gPTP messages are transmitted on a QoS Flow that complies with the residence time upper bound requirement specified in IEEE 802.1AS .
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 as follows:
Adds the calculated residence time expressed in TSN GM time to the correction field.
Each TSN working domain sends its own gPTP messages. The related Ethernet frames carry the gPTP multicast Ethernet destination MAC address and the gPTP message carries a specific PTP "domainNumber" that indicates the time domain they are referring to. The NW-TT makes ingress timestamping (TSi) for the gPTP event messages of all domains and forwards the gPTP messages of all domains to the UEs as specified in clause 220.127.116.11.2.
A UE receives gPTP messages and forwards them all to the DS-TT. The DS-TT receives the original TSN clock timing information and the corresponding TSi via gPTP messages for one or more TSN working domains. The DS-TT then makes egress timestamping (TSe) for the gPTP event messages for every external TSN working domain. Ingress and egress time stamping is based on the 5G system clock at NW-TT and DS-TT.
The process described in "Distribution of TSN clock and time-stamping" is thus repeated for each TSN working domain between a DS-TT and the NW-TT it is connected to.
This feature allows the 5GS to support 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 TSN).
The features include the following:
Providing TSC Assistance Information (TSCAI) that describe TSC flow traffic patterns at the gNB ingress and UE egress interfaces for traffic in downlink and uplink direction, respectively;
Support for hold & forward buffering mechanism in DS-TT and NW-TT to de-jitter flows that have traversed the 5G System.
TSC assistance information describes TSC traffic characteristics for use in the 5G System. The knowledge of TSN traffic pattern is useful for the gNB to allow it to more efficiently schedule periodic, deterministic traffic flows either via Configured Grants, Semi-Persistent Scheduling or with dynamic grants. TSC assistance information, as defined in Table 5.27.2-1, is provided from SMF to 5G-AN, e.g. upon QoS Flow establishment. The TSCAI parameters are set according to corresponding parameters obtained from the TSN AF. The TSN AF identifies the PDU session as described in clause 5.28.2.
The TSN AF is responsible for obtaining PSFP (IEEE 802.1Q ) parameters and use them to calculate traffic pattern parameters (such as burst arrival time with reference to the ingress port, periodicity, and flow direction) and responsible of forwarding these parameters in TSC Assistance Container to the SMF (via PCF). 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. One set of parameters and one container are being calculated by the 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.
In this case, TSN AF creates one TSC Assistance Container for the aggregated TSN streams. The SMF will bind PCC rules with a TSC Assistance Container as described in clause 18.104.22.168.4 of TS 23.503. The SMF derives TSCAI on a per QoS Flow basis and send it to 5G-AN. The Burst Arrival Time and Periodicity component of the TSCAI that the SMF signals to the 5G-AN are specified with respect to the 5G clock. The SMF is responsible for mapping the Burst Arrival Time and Periodicity from a TSN clock to the 5G clock based on the time offset and cumulative rateRatio between TSN 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 TSN 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 22.214.171.124.
For traffic in uplink direction, the SMF corrects the Burst Arrival Time in the TSN 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.
The SMF corrects the Periodicity in the TSN Assistance Container by the previously received cumulative rateRatio from the UPF and sets the TSCAI Periodicity as the corrected value.
The SMF sets the TSCAI Flow Direction as the Flow Direction in the TSN Assistance Container.
In the case of drift between TSN time and 5G time, the UPF updates the offset to SMF using the N4 Report Procedure as defined in TS 23.502, clause 126.96.36.199. In the case of change of cumulative rateRatio between TSN time and 5G time, the UPF updates the cumulative rateRatio to SMF using the N4 Report Procedure as defined in TS 23.502, clause 188.8.131.52. The SMF may then trigger a PDU Session Modification as defined in TS 23.502, clause 4.3.3 in order to update the TSCAI parameter to the NG-RAN without requiring AN or N1 specific signalling exchange with the UE.
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:
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 that was set for this traffic class. The maximum value of TSC Burst Size should be mapped to a 5QI with MDBV that is equal or higher. This 5QI also shall have a PDB value that satisfies the bridge delay capabilities 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, and the PDB of this 5QI shall also satisfy the bridge delay capabilities reported.
The PDB is explicitly divided into 5G-AN PDB and CN PDB as described in clause 184.108.40.206. 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 220.127.116.11. The CN PDB may be static value or dynamic value and is up to the implementation of 5GS bridge.
The Maximum Flow Bitrate calculated by the TSN AF as per Annex I.1 may be used to set GFBR.
DS-TT and NW-TT support a hold and forward mechanism to schedule traffic as defined in IEEE 802.1Q  if 5GS is to participate transparently as a bridge in a TSN network. The Hold and Forward buffering mechanism allows PDB based 5GS QoS to be used for TSC traffic since packets need only arrive at NW-TT or DS-TT egress prior to their scheduled transmission time.
5GS provides AdminControlList and AdminBaseTime as defined in IEEE 802.1Q  on a per Ethernet port basis to DS-TT and NW-TT for the hold and forward buffer as described in clause 5.28.3.
In order for the 5G System to participate as a TSN bridge according to gate schedules specified, the 5GS Bridge is required to provide Bridge Delays as defined in IEEE 802.1Qcc  for each port pair and traffic class of the 5GS bridge to an IEEE TSN system. In order to determine 5GS Bridge Delays, the following components are needed:
UE-DS-TT Residence Time: the time taken within the UE and DS-TT to forward a packet between the UE and DS-TT port. UE-DS-TT Residence Time is provided at the time of PDU Session Establishment by the UE to the network.
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.
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 802.1Qcc .
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 serving NW-TT Ethernet port(s) when the TSN AF receives the 5GS Bridge information for a newly established PDU Session and caculates the bridge delays per port pair.