5G/NR - Time-Sensitive Networking
A factory controller needs more than a short average packet delay. Its packets must arrive within the required time window, and devices must agree on time closely enough to act together. 5G TSN integration connects these requirements to Ethernet bridge behavior, 5G QoS and radio scheduling.
This focused note covers the
- Executive Summary
- Why URLLC alone is not the whole solution
- Rel-16: The 5GS as a logical TSN bridge
- How does TSN time cross the 5G system ?
- How are TSN schedules mapped to 5G QoS ?
- Rel-17 and Rel-18 evolution
- What should be checked in a deployment ?
- Reference
Executive Summary
TSN is a family of IEEE Ethernet mechanisms. 3GPP defines how the 5G System participates in that environment and how it provides broader time-sensitive communication and synchronization services.
Topic | Main point |
|---|---|
Rel-16 baseline | The 5GS appears as a logical TSN bridge, with DS-TT and NW-TT ports and a TSN AF interfacing with centralized TSN control. |
Time synchronization | The 5G internal clock and the external TSN grandmaster clock are distinct concepts. Translators account for residence time when forwarding gPTP. |
Traffic scheduling | TSN stream requirements are mapped to 5G QoS. TSCAI provides traffic timing assistance to NG-RAN; it is not a radio grant. |
Rel-17 evolution | TSCTSF supports AF-requested time-sensitive communication and time-synchronization services, including operation beyond a TSN/CNC integration. |
Rel-18 evolution | Timing-status monitoring, application scheduling adaptation using RAN feedback, and interworking with TSN in the transport network extend the baseline. |
Engineering limit | A low-latency 5QI or a synchronized clock alone does not guarantee a deadline across the complete application path. |
Why URLLC alone is not the whole solution
URLLC addresses demanding latency and reliability requirements, but an industrial path also includes endpoint processing, Ethernet links, queues and a transport network. A radio improvement helps only the part of the deadline budget spent on that radio path.
Delay, jitter, loss and clock error
These quantities describe different failures. Delay measures how long delivery takes. Jitter measures its variation. Reliability concerns successful delivery under defined conditions. Clock error measures disagreement between time references, even when the packet itself arrives quickly.
An actuator can receive every packet and still act too late. It can also receive packets on time but act at the wrong instant because its clock is offset. A meaningful requirement therefore identifies the measurement endpoints, deadline, acceptable loss and synchronization accuracy. An average ping result cannot establish all of these properties.
TSN versus TSC
IEEE TSN supplies Ethernet mechanisms for predictable communication, including synchronization, scheduled traffic and stream control. 3GPP Time Sensitive Communication (TSC) is a broader service concept. Some TSC services do not need an external TSN controller or an Ethernet bridge model.
Rel-16 integration uses the fully centralized TSN configuration model. The Centralized Network Configuration function (CNC) handles the network configuration, while application requirements are supplied through the TSN configuration environment. The 5GS exposes bridge capabilities and accepts configuration through a TSN Application Function (TSN AF). This creates an end-to-end coordination problem rather than a single new PHY feature.
The URLLC note explains latency-reduction techniques. The 5G QoS note explains how the network represents packet treatment. TSN integration connects those functions to streams, ports and timing requirements outside the radio system.
Specify the full path and separate delivery deadlines from clock accuracy before selecting radio or QoS parameters.
Rel-16: The 5GS as a logical TSN bridge
An external TSN network should not need to understand a radio bearer or the internal 5G tunnel structure. The logical bridge abstraction exposes Ethernet ports and bridge behavior while the 5GS handles its own session and radio procedures internally.
DS-TT, NW-TT and TSN AF
The Device-side TSN Translator (DS-TT) provides the device-side boundary, and the Network-side TSN Translator (NW-TT) provides the network-side boundary associated with the UPF. The DS-TT may be integrated with UE or implemented separately; that packaging is implementation dependent.
The TSN AF supplies control-plane translation toward the CNC. It is not a user-plane forwarding hop. PCF and SMF participate in policy and session handling, while the UE, NG-RAN and UPF transport the traffic. Ethernet PDU sessions provide the user-plane context for this bridge integration.
Figure 1 shows a simplified downlink path through the logical bridge. The dashed control connections represent configuration relationships, not additional Ethernet forwarding links. One bridge can expose multiple ports; only one device-side path is drawn.
Figure 1. Simplified Rel-16 architecture, with the internal radio and core path hidden behind TSN ports.
Bridge capabilities and stream admission
The CNC needs bridge information before it can build a feasible schedule. Port identity and connectivity matter, but so do the delays between ingress and egress ports for each traffic class. These are capabilities to configure against, not just performance measurements after deployment.
The TSN AF obtains relevant 5GS bridge and port information and presents it to TSN control. Stream requirements are translated into policy and QoS handling within the 5GS. A stream may share a QoS Flow with other compatible traffic; the stream-to-flow relationship is not universally one-to-one.
The bridge model does not mean that any Ethernet stream is automatically admitted. The network must support the requested traffic profile and available resources must satisfy it. A change of port, path or QoS feasibility can require configuration updates. The CNC should not continue using stale bridge assumptions after such changes.
The TSN AF handles control translation; the DS-TT and NW-TT provide the observable boundaries of the user-plane bridge.
How does TSN time cross the 5G system ?
Synchronization packets experience variable transport delay just like other packets. Forwarding them without accounting for that delay would confuse transport time with clock offset. The translators therefore timestamp the relevant messages and account for their residence inside the 5GS.
5G time and TSN grandmaster time
The 5G internal clock synchronizes the relevant 5GS nodes. The TSN grandmaster provides the external working-domain time. These clocks need not be the same source, and multiple TSN working domains can coexist with the 5G timing system.
In the Rel-16 downlink example, the NW-TT timestamps a gPTP Sync message at ingress. UE receives 5G reference timing from NG-RAN and makes it available to DS-TT. The DS-TT timestamps the message at egress using the synchronized 5G time base. Their timestamp difference measures residence time in that time base.
The translator converts residence time to the TSN grandmaster time scale using the applicable rate-ratio information and updates the gPTP correction field. The external receiver can then account for transit through the bridge. This operation does not require gNB to become a separate external TSN bridge for every radio hop.
Residence time is not synchronization error
A packet can spend a substantial time inside a bridge while still conveying accurate time if that residence time is measured and corrected accurately. Conversely, a short packet delay can coexist with a large clock error if timestamping or synchronization is inaccurate.
As a simplified calculation, an ingress timestamp of 10.000 ms and an egress timestamp of 10.300 ms imply 300 microseconds of residence time. If the two clocks disagree by 5 microseconds, their subtraction contains that error. Correcting for 300 microseconds does not automatically remove the clock disagreement. This example assumes equal clock rates only to isolate the distinction.
The synchronization error budget must include the relevant clock distribution and timestamp uncertainties. Radio propagation compensation, clock drift and translator implementation can matter. A PDB is a packet-delay parameter; it is not a time-synchronization accuracy guarantee. Similarly, delivery of timing information through RRC does not by itself establish compliance at the external application clock.
Keep residence time, clock-rate conversion and residual synchronization error separate in measurements and explanations.
How are TSN schedules mapped to 5G QoS ?
A TSN gate schedule describes when traffic may leave a port. A radio scheduler decides when to allocate radio resources. The 5GS must connect these decisions through traffic characteristics and delay budgets without exposing every radio scheduling detail to the CNC.
TSCAI, PDB and maximum burst volume
Time Sensitive Communication Assistance Information (TSCAI) gives NG-RAN information about traffic direction, periodicity and burst arrival time. The network derives it for the QoS Flow. It helps anticipate traffic, but it is not a DCI grant or a guarantee of a specific transmission slot.
In Rel-16 TSN integration, the TSN AF supplies traffic assistance information and the SMF derives the information sent to NG-RAN. The SMF converts the relevant time quantities from TSN time to the 5G clock domain. Downlink and uplink calculations use different path-delay components, so one unqualified timestamp should not be applied to both directions.
Parameter / concept | What it controls |
|---|---|
Periodicity and Burst Arrival Time | Expected traffic timing in the applicable reference clock; useful for scheduling preparation. |
Packet Delay Budget (PDB) | Delay allowance over its specified endpoints. The 5G-AN and core-network portions must fit the relevant total budget. |
Maximum Data Burst Volume (MDBV) | Burst volume associated with delay-critical GBR treatment; average bitrate alone does not describe a burst. |
GFBR / MFBR | Guaranteed and maximum flow bitrates, interpreted together with burst and delay characteristics. |
5QI and packet error rate | QoS characteristics for packet handling; they do not independently prove complete application-path compliance. |
Bridge delay and gate configuration | The bridge behavior exposed to TSN control, including the port pair and traffic class. |
Why hold a packet that arrived early ?
An early packet can be held at an egress translator and released at its scheduled opportunity. This reduces output timing variation when hold-and-forward functionality is used. It deliberately adds waiting time, so it must be included in the latency budget.
Figure 2 uses a hypothetical schedule with one release opportunity every millisecond. The internal path delivers each packet at a different time, but all three are ready before their release opportunity. A packet arriving after its intended opportunity cannot be repaired by holding it.
Figure 2. Hold-and-forward regularizes output timing for packets that arrive before the scheduled opportunity.
For a numerical budget example, suppose the application allows 2 ms end to end. If endpoints and external links consume 0.7 ms and the design reserves 0.3 ms margin, only 1.0 ms remains for the 5GS segment. An internal 0.8 ms transit plus 0.4 ms hold time would exceed that allowance. These are illustrative values, not standardized 5G TSN performance guarantees.
Treat scheduled waiting as real latency. Match burst volume, clock domain and complete delay budget before admitting the stream.
Rel-17 and Rel-18 evolution
The releases extend different parts of the system. Rel-17 broadens access to time-sensitive and synchronization services, while Rel-18 adds tools to observe timing quality and coordinate traffic more closely. These capabilities remain dependent on implementation, subscription and configuration.
Rel-17: TSCTSF and AF-requested services
The Time Sensitive Communication and Time Synchronization Function (TSCTSF) supports application-requested services beyond the original CNC-based bridge integration. An AF can access the exposed functionality through NEF, or directly where the operator trusts that AF.
For time synchronization, the AF can discover availability and capabilities and request activation or deactivation for target UEs. The service can use (g)PTP distribution or 5G access-stratum time distribution. The requested synchronization error budget defines a bound on error introduced by the 5GS, rather than a packet-delivery deadline.
The Rel-17 architecture supports relevant synchronization services with Ethernet or IP PDU sessions. TSCTSF controls translator functions for (g)PTP-based service and supports TSC assistance handling. TSCTSF and TSN AF should therefore not be treated as interchangeable names: the TSN AF serves TSN integration, while TSCTSF supports the broader service-exposure architecture.
Rel-18: timing resiliency and traffic adaptation
Timing quality can degrade after a synchronization service starts. Rel-18 introduces monitoring and reporting so consumers can learn about such changes. Reportable information can include synchronization state, traceability, clock accuracy, frequency stability and the parent time source.
TSCTSF can receive timing-status information and notify subscribed applications. For access-stratum timing service, UE can receive clock-quality information from NG-RAN under the applicable controls. Monitoring does not make a failed clock accurate again; it lets the service or application respond to the detected condition.
Rel-18 also supports application burst-timing and periodicity adaptation using RAN feedback. An application that can adjust its traffic timing may reduce the wait until an available radio opportunity. The feature has specific capability and signalling conditions; it does not let the application directly select arbitrary radio resources.
Another Rel-18 addition concerns TSN deployed inside the transport network carrying 5G traffic. Coordinating that transport with QoS requirements is a different integration point from presenting the complete 5GS as a TSN bridge to an external industrial network. Both can matter on the same end-to-end path.
Separate service exposure, timing-status reporting and transport-network coordination when comparing Rel-16, Rel-17 and Rel-18 support.
What should be checked in a deployment ?
A successful registration and an established PDU session are only the starting conditions. Verification needs evidence for the stream mapping, the available resources and the clock behavior at the relevant endpoints. A feature label is not enough to establish those results.
Configuration and measurement evidence
Collect the application traffic profile and the network configuration together. A periodic stream with unexpected burst size can violate assumptions even when its average rate looks correct. Measurements should retain the clock reference and the locations where timestamps were taken.
Check | Useful evidence |
|---|---|
Bridge and port configuration | DS-TT/NW-TT identities, port connectivity, bridge-delay information and CNC configuration. |
Stream-to-QoS mapping | Stream filters, QFI, PDU session, selected 5QI, bitrate limits, MDBV and delay budget. |
Scheduling assistance | TSCAI direction, period and burst timing in the correct clock domain; subsequent updates. |
Time distribution | Grandmaster/domain identity, ingress/egress timestamping, correction behavior and endpoint clock error. |
Failure conditions | Deadline misses, loss, clock degradation, traffic overload and behavior after path changes. |
Release-specific service | TSN AF or TSCTSF role, requested capabilities and actual Rel-17/18 configuration rather than release branding. |
Common causes of a misleading result
Compare deadline misses with packet loss separately. Retransmission can recover a packet after its deadline, which is still a failure for some control loops. A good packet error result can therefore coexist with poor application reliability.
Likewise, an accurate clock measured at gNB does not prove the same accuracy at the external device. Include UE, translator and endpoint contributions. Mobility, congestion and loss of a clock source should be evaluated against the admitted service conditions, including what happens when the requested behavior can no longer be maintained.
This note describes architecture and procedures, not a measured product guarantee. For radio scheduling options, refer to Configured Scheduling. For resource and delay treatment, refer to QoS. Use the URLLC note alongside these when assessing the radio contribution to the complete path.
Validate at the application endpoints, with explicit traffic assumptions and clock references, rather than relying on average network latency.
Reference
The architecture, synchronization, TSCAI and TSN-integration clauses were consulted, rather than every clause of these specifications. The separate release versions below make the baseline and evolution explicit. No ASN.1 or captured signalling dump is reproduced in this note.
- TS 23.501 v16.14.0: Rel-16 architecture, section 4.4.8; TSC enablers and TSN integration, sections 5.27 and 5.28.
- TS 23.501 v17.9.0: AF-requested service architecture, section 4.4.8.3; synchronization exposure and TSCTSF functions.
- TS 23.501 v18.8.0: Timing-status monitoring in section 5.27.1.12 and scheduling-assistance evolution in section 5.27.2.
- TR 21.918 v18.0.0: Section 6.5: timing resiliency, TSN transport-network interworking and RAN feedback for traffic adaptation.