Synchronizing TSN Devices via 802.1AS over 5G Networks

1. Introduction

TSN has become an integral part of modern industrial communication, automation, and automotives communication. It enables strict deadlines in automation and synchronous communication along with coordination between machines in industry 4.0. Similarly, TSN fulfils prioritized communication with strict quality of service requirements in automotives industry e.g. automated self-driving vehicles, where machine response times in order of microseconds are required. With 5G release 16 and 17, 5G systems are also capable of providing TSN services enabling wide range of remote healthcare services e.g. remote operation procedures, too. While 5G standards incorporate TSN functionality, it also significantly adds to the complexity of the 5G system, therefore there are very limited available implementations of 5G system which integrate TSN in hardware or in software.

One of the first steps in TSN-5G integration is to support time synchronization of TSN devices through the 5G network. Since TSN time synchronization messages are based on Ethernet frames, they cannot be carried through a 5G network unless it supports Ethernet PDU transport. A possible workaround is to encapsulate the Ethernet PDUs within IP PDUs. We therefore implemented the encapsulation of Ethernet frames in UDP/IP packets in the OMNeT++ based Simu5G simulator, as it so far only supports an IP PDU transport.

The major contributions of this paper are as following:

Integration of time synchronization for TSN in a 5G Simulator framework model

Performance simulation for TSN time synchronization through 5G downlink

Performance Simulation for TSN time synchronization in a 5G handover scenario

Analysis of factors impacting synchronization accuracy in 5G network

The next sections are structured as follows: Section 2 describes the basics of TSN along with the time synchronization procedure of the TSN standard. Section 3 gives an overview of the current research in the field of TSN time synchronization using 5G network as a communication link. Integration of TSN and 5G, with focus on time synchronization, is given in section 4. It also discusses the implementation of various models and simulation scenarios created using those models to evaluate the performance of TSN time synchronization using encapsulation over the 5G System (5GS). Section 5 analysis the result of the simulations. And finally, section 6 concludes the paper.

2. Time Sensitive Networking

Time Sensitive Networking (TSN) standards enable determinism, ultra-reliable and low latency communication in Ethernet networks and being the industry standard ensures interoperability between manufacturers. The TSN standards encompass various extensions for the IEEE 802.1Q standard for VLANs in bridged networks. As TSN mainly focuses on real-time communication in bridged networks, its standards are separated into four major categories, each aiming to guarantee quality of service to specific real-time traffic. These main categories are Time Synchronization to synchronize all network devices to a network master, Bounded Low Latency for deterministic end to end latency in the network, Ultra Reliability for data prioritization with end-to-end route reservation in addition to path redundancy, and Resource Management for managing the network devices through a network devices coordinator and configurator. Table 1 gives an overview of TSN standards in each of the mentioned categories.

Each TSN component is briefly described in the next subsections. Time Synchronization is discussed in detail as it is crucial for understanding the simulation results presented later in section 5.

2.1. Resource Management

Resource Management in a TSN network is realized via various protocols and standards, each optimizing and managing specific functionality on the TSN core and end-devices. The Stream Reservation Protocol (SRP) (IEEE 802.1Qat standard) provides the basis of reserving the network resources from the talker to the listener. SRP implements a decentralized stream reservation procedure, in which the listener and the talker directly communicates to reserve resources for the streams. While this reserves the streams but there might arise situations where stream reservations between different talkers and listeners try to overrule each other, resulting in poor performance of all of the streams. Therefore, IEEE 802.1Qcc implements enhancements to SRP standard makes SRP centralized by running the reservation protocol on a Centralized Network Configurator (CNC). Having information about the complete network topology, CNC is able to centrally assign path resources e.g. low latency queues, interface bandwidth, high priority gates, to the specified stream between talker and listener. CNC, depending on the network topology information, computes Gate Control Lists (GCL) via user defined algorithms and device configuration files using YANG (a UML based data modelling language). These configurations are then pushed to the respective devices via NETCONF. Meanwhile RESTCONF can be used for User Network Interface (UNI) to configure the CNC.

The IEEE standards 802.1Qcp, Qcw and Qcbcv define YANG models for the CNC to configure the bridging, traffic scheduling, filtering, frame replication and elimination functionality for TSN bridges.

2.2. Bounded Low Latency

Ensuring that data packets reach the destination within the application specified time requirements is of utmost importance in real-time networks. TSN makes use of VLAN Tagging and implements extensions to IEEE 802.1Q standard.

To achieve guaranteed end-to-end latency, traffic shaping standards are used to reduce buffering of frames in bridge devices. A Credit-Based Shaping (CBS) mechanism is defined in IEEE 802.1Qav [3], which allows bandwidth reservation for up to eight distinct traffic classes. Each traffic queue is assigned a class and is associated with an idleSlope parameter that adds credits to the queue, which are required to transmit frames. Depending on the queue class and the number of frames in the queue, credits are increased or decreased and depending on the available credits, frames from the queue are forwarded.

A Time-Aware Scheduling mechanism is defined in IEEE 802.1Qbv [4]. Time Aware Shaper (TAS) adds a transmission gate to each queue, which opens and closes, allowing the transmission of frames. The state of the gates is controlled by a Gate Control List (GCL), computed by CNC. The entries in the GCL are set as the current configuration for a specified time, beginning with the first entry. After all entries have been applied, the cycle is repeated.

Frame preemption is defined in IEEE 802.1Qbu, allowing the interruption of low priority frame transmission if a high priority frame is received for forwarding.

2.3. Ultra Reliability

TSN extends the 802.1Q Bridging standard and adds Path Control and Reservation (PCR), and Per-Stream Filtering and Policing (PSFP) standards to guarantee reliable frame delivery between source and destination. PCR extends Shortest Path Forwarding (SPF), which is based on Intermediate System-Intermediate System (IS-IS) protocol to Explicit Paths Determination using Path Computation Element. This allows the CNC to have granular control of paths and to reserve paths for streams with high reliability requirements. Reserved paths could be point to point, point to multipoint, or multipoint to multipoint connections.

Frame Replication and Elimination enables TSN bridges to duplicate the frames and transmit over alternative paths to ensure reliability. The TSN bridge at the receiving end then eliminates the duplicate frames and forward the remaining frames to the destination. PSFP adds ingress traffic policing to the bridges via filtering based on pre-defined rules which can be streamID matching, priority level matching, service class selection, or even frame counting.

2.4. Time Synchronization

Time Synchronization is a key requirement of real-time networks; thus, it is of utmost importance and a basic component of TSN. It enables TSN devices to adjust and correct their local clocks in reference to the Grand Master clock. This is a prerequisite for gate scheduling mechanisms, path reservation, traffic filtering and forwarding and traffic shaping via TAS or CBS. Time Synchronization for TSN is standardized in IEEE 802.1AS with the gPTP profile for the IEEE 1588v2 Precision Time Protocol (PTP). It provides sub-microsecond accuracy in synchronization. The Time Synchronization mechanisms is shown in figure 1.

Figure 1. IEEE 802.1AS Time Synchronization procedure in wired networks.

Figure 1. IEEE 802.1AS Time Synchronization procedure in wired networks.

The synchronization procedure consists of the Requester entity (TSN device which wants to synchronize to the master) requesting the Responder entity (TSN device to which all other TSN devices synchronize to) to initialize the synchronization process. After initialization, the Requester sends a Path delay measurement request to the Responder, which responds with a Path delay measurement response and a follow-up message. In this three-message exchange, the Requester gathers four time stamps, as shown in figure 1. In the Propagation delay measurement process, a symmetric link is assumed. This is true for wired networks, but for wireless networks, with asymmetric links, this assumption can adversely affect the outcome of the synchronization, as we will see in the section 5 of this paper.

After the Propagation delay measurement process, a Synchronization message and a Synchronization follow-up message are sent by the Responder with the current timestamp (preciseOriginTimestamp). Using the current time, the previously computed Propagation delay, and the correction field (in case if the Responder is not the Grand Master), the Requester computes the actual time using the following equation and adjusts its local clock accordingly.

Corrected Time = preciseOriginTimestamp + Propagation Delay + correction field

For integration of TSN and 5G network, it is important for 5G network to provide the required QoS to the TSN communication streams. This also implies that Time Synchronization messages of TSN network shall traverse through 5G system in order for TSN end devices on the either side of 5GS to synchronize. But with handovers in 5GS and channel access grants for UE to access channel for data transmission results in irregular Propagation delay calculations which decreases the synchronization accuracy as compared to a symmetric 5G link i.e. same propagation delay in uplink and downlink.

3. Related Research

3GPP Release 16 and 17 integrates TSN functionality in 5G networks. This is an active and evolving research area, and TSN 5G integration is not feasible until Time Synchronization between TSN devices over 5G does not fulfil the accuracy requirements of the IEEE 802.1AS standard.

In [1], Thi et al. created TSN over Wi-Fi and over 5G mobile networks using common of the shelf (COTS) devices. They tested the networks for single hop and two hop performance of 802.1AS over wireless links and found that with COTS devices, successful synchronization, that meets the standards of Industrial TSN (sub-microsecond accuracy), cannot be achieved. Their results show a time synchronization accuracy of up-to 2.5 milliseconds in best case scenarios for 5G links. They also show that, due to the variations in the jitter and the measured propagation delay, accurate synchronization is not achieved.

Gundall et al. in [2] implemented 802.1AS based Time Synchronization over 5GS in a hardware test setup. Their findings state that < 1 millisecond accuracy can be achieved with 802.1AS Time Synchronization over 5G.

Shi et al. [5] published an analytic framework and showed that sub-microsecond accuracy can theoretically be achieved, if different errors, such as error in path delay estimation and error in time of arrival estimation, associated with reference time indication are minimized. They also mention that variations and errors in propagation delay estimation can have significant impact on the synchronization accuracy as we show in our simulations.

Schüngel, et al. in [6] present a formulation method for error computation in time synchronization mechanisms for TSN and 5G integration. The paper considers a maximum error of 50.5 nanoseconds for propagation delay measurement and a symmetric 5G link is assumed. Their model calculated synchronization errors of up to 8ns after successful synchronization. The paper focuses on minimizing error rate during synchronization while assuming 50 nanoseconds symmetric link delay in wired and wireless links, which is unrealistic.

The next section describes the method implemented and used for synchronizing TSN devices over a 5G network and the scenarios simulated to test the synchronization accuracy.

4. Simulation Setup for TSN Synchronization over 5G Scenarios

5G Release 16 supports TSN time synchronization by enabling the 5GS as a TSN bridge. The entire end to end 5GS is considered a Time-Aware System meaning that 5G System is able to provide time critical services to TSN. Only the edges of the 5GS must support IEEE 802.1AS operations, while inside 5GS, a separate synchronization mechanism is used for the 5GS specific elements. As a time-aware system, 5GS calculates and adds the measured residence time between its network edges to the Correction Field of the synchronization messages.

3GPP Release 17 adds a Time Translator (TT) functionality on the edges of 5GS – the so-called Network Side TT (NW-TT) and Device Side TT (DS-TT). NW-TT and DS-TT updates the rateRatio fields of the passing though synchronization messages. RateRatio is the ratio of clock oscillator frequencies of the Master and the Slave node. It is used to update the gathered timestamps to the common time base. To compute the residence time, the 5GS ingress side (i.e. the 5G component which receives the sync messages which are to be forwarded over the 5GS) adds an ingress timestamp to the sync messages. When the message is leaving the 5GS, the TT at the egress side adds the egress timestamp in the message. Upon reception of the message at a TSN device, the egress and ingress timestamps are used to calculate the time that the message spent within the 5GS. This residence time is used in the correction field calculations during the synchronization process. Although the procedures for TSN time synchronization over a 5G System are standardized, the propagation delay measurement still assumes symmetric uplink and downlink, which could introduce errors and reduce the synchronization accuracy significantly. A way to cater the asymmetry could be using the averaged downlink timestamps from the previous synchronization cycles for the synchronization in downlink. Similar can be done for synchronization in uplink.

Very few tools are available to simulate 5G networks and Time Sensitive Networks together. While NS-3 [7], Riverbed [8] and OMNeT++ can be used to simulate TSN functionality, and NYUSIM [9], Vienna LTE Simulator [10, 11], WiSE [12] etc. can be used to simulate 5G functionality [13], only OMNeT++ offers both TSN and (at least partially) 5GS simulation capabilities.

4.1. OMNeT+ based simulation framework

Our simulation studies were carried out with the discrete event simulator OMNeT++ [14]. OMNeT++ has various frameworks, which provide different functionalities - for example, the Simu5G [15] framework comprises basic 5G User plane functions. INET [16], another major OMNeT++ framework, includes a OSI layer model and multiple protocol options for these layers. INET also contains Time Sensitive Networking functionality at the Data Link Layer. Therefore, for the simulation studies presented in this paper, both the Simu5G and the INET framework are used as the base. Using these frameworks, new nodes are created which contains both 5G NIC and Ethernet NIC for TSN. The already existing 5G UE model in Simu5G is updated to include time synchronization functionality and a TSN Bridge model, from the INET framework, is updated with a modified 802.1AS functionality (sync message encapsulation in UDP/IP packets) so that time synchronization messages can be forwarded through the 5GS (which in Simu5G only supports the transmission of IP PDUs).

4.1.1. Updated 802.1AS Model

The 802.1AS model in the INET framework implements the time synchronization mechanism exactly as mentioned in the previous section. The TSN nodes which forward TSN messages into the 5G network and vice versa needs to be updated. The encapsulation and decapsulation of time synchronization messages into layer 3 (UDP/IP) PDUs have to be implemented. The sync frames are forwarded, encapsulated within IP PDUs in the 5GS and once they reach the 5G TSN boundary, decapsulation is performed and further forwarding in the TSN network relies on layer 2 (MAC) addressing. This means that encapsulation is done at the ingress 5G TSN boundary node and decapsulation at the egress boundary node. Furthermore, depending on the TSN Grand Master positioning in the simulation scenario, 5G TSN boundary nodes can be set up as ingress or egress boundary nodes in the updated 802.1AS model. This is used in simulating time synchronization scenarios, where the TSN Grand Master can be located in either uplink or downlink, thus the synchronizing device would be located on the opposite side of the 5G network.

4.1.2.5. G-TSN Device

The INET framework contains a TSN Bridge model, which is inherently an Ethernet Switch with TSN functionality. For 5G TSN integration and TSN frames being forwarded over a 5G network using IP PDUs, layer 3 functionality is required at the boundary devices. Since TSN Bridges don’t provide layer 3 addressing, the existing INET Ethernet Router model is extended to include TSN functionality for layer 3 forwarding, encapsulation, and decapsulation. In addition to TSN functionality, 5G NIC is also added in the model, so it also can be used as a 5G UE, instead of separately updating Simu5G’s UE model to incorporate TSN time synchronization functionality. Finally, as the router has to receive, process, and forward time synchronization frames, the updated 802.1AS model mentioned in the previous subsection is added in the created device model.

4.2. Simulation Scenarios

Using the updated models, two simulation scenarios are created. Starting with a simple TSN network consisting of two TSN switches and a Grand Master (GM). The GM, called TSN Master is connected to the TSN Switch (based on 5G-TSN device model), which is in turn connected to the second TSN Switch (also based on 5G-TSN device model). The link between both switches is simulated by a 5G network.

4.2.1. Simulation Scenario 1

In the first scenario, the GM is placed on the server side of the 5G network. That means synchronization messages are transferred in the downlink. Both TSN Switches are 5G-TSN devices; the first being named TSN Switch, encapsulates the time synchronization messages and forwards them to the 5G network. The second 5G-TSN device, named TSN device 2, acts as a TSN device capable of synchronizing to the GM through the 5G network. It receives encapsulated time synchronization messages, decapsulates them and synchronizes itself with the GM via the extracted messages. From the perspective of TSN devices, the 5G network is simply a link between TSN Switch and the TSN device 2. This simulation scenario is shown in figure 2 (a).

The scenario can be expanded by connecting TSN devices to the GM (TSN Master), TSN Switch, and TSN device 2, if it takes the role of a TSN Bridge, in figure 2 (a) resulting in a hierarchical structure.

4.2.2. Simulation Scenario 2

This scenario is similar to scenario 1 in terms of the TSN network layout but differs in the layout of the 5G network. The 5G network now has two gNodeBs. The TSN device 2 is mobile and moves along a predefined path at a constant speed. This results in a handover between the gNBs, and while the handover is taking place, the synchronization process is affected due to the variation in the propagation delay. This simulation scenario is shown in figure 2 (b).

Both simulation scenarios are run for 500 seconds. Time synchronization occurs in 1 second intervals, and the propagation delay measurement interval is also set to 1 second. TSN device 1, TSN Switch, and TSN device 2 synchronize to the TSN Master, and the local device’s clock time of the Master clock and the slave clocks, immediately before and after synchronization, are logged. In addition, propagation delay, residence time, and all four timestamps required for propagation delay measurement are also logged. Since these timestamps are used to calculate the link delay, they can be used to measure uplink and downlink delay, the delay variations, and the difference between uplink and downlink delay in the 5G network.

Figure 2. (a) Simulation Scenario 1: TSN device 2 synchronizes with TSN Master via TSN Switch; (b) Simulation Scenario 2: Extension of scenario 1; handover between gNodeB1 and gNodeB2.

Figure 2. (a) Simulation Scenario 1: TSN device 2 synchronizes with TSN Master via TSN Switch; (b) Simulation Scenario 2: Extension of scenario 1; handover between gNodeB1 and gNodeB2.

The major simulation parameters are shown in table 2. Simulation scenario 2 is an extension of simulation scenario 1 – therefore the same parameters as in simulation scenario 1 are applied and additional mobility and handover specific parameters.

Table 2. Simulation parameters.

TSN network parameter *			Value	5G network parameter *		Value
Simulation 1	Ethernet Bitrate		1 Gbps	AMC 1 Type		NRAmc
	Oscillator Type		Constant Drift Oscillator	Target BLER 2		0.01
	Oscillator Drift Rate		Uniform (0 ppm, 100 ppm)	BLER Shift		5
	Local/Destination UDP Ports		3000	Mac Cell ID / Master ID		0
	Sync Initial Offset / PDelay Initial Offset		1 s	NR Mac Cell ID / NR Master ID		1
	Sync / PDelay Interval		1 s
Simulation 2	UE Mobility	Mobility Type	Rectangle Mobility	Handover	CQI Feedback Period	40ms
		Constraint Area	(150m, 450m) – (750m, 450m)		Uplink/downlink interference	True
		Starting Position	(0, 0) i.e. (150m, 450m)		Dynamic Cell Association	True
		Speed	2 meters/second		Enable Handover	True

* TSN / 5G parameters not mentioned in table are set to the default values as specified in their OMNeT++ model. ¹ Adaptive Modulation and Coding ² Block Error Rate.

Table 2. Simulation parameters.

TSN network parameter *			Value	5G network parameter *		Value
Simulation 1	Ethernet Bitrate		1 Gbps	AMC 1 Type		NRAmc
	Oscillator Type		Constant Drift Oscillator	Target BLER 2		0.01
	Oscillator Drift Rate		Uniform (0 ppm, 100 ppm)	BLER Shift		5
	Local/Destination UDP Ports		3000	Mac Cell ID / Master ID		0
	Sync Initial Offset / PDelay Initial Offset		1 s	NR Mac Cell ID / NR Master ID		1
	Sync / PDelay Interval		1 s
Simulation 2	UE Mobility	Mobility Type	Rectangle Mobility	Handover	CQI Feedback Period	40ms
		Constraint Area	(150m, 450m) – (750m, 450m)		Uplink/downlink interference	True
		Starting Position	(0, 0) i.e. (150m, 450m)		Dynamic Cell Association	True
		Speed	2 meters/second		Enable Handover	True

* TSN / 5G parameters not mentioned in table are set to the default values as specified in their OMNeT++ model. ¹ Adaptive Modulation and Coding ² Block Error Rate.

5. Simulation Results and Discussion

5.1. Simulation Scenario 1

The TSN Switch directly synchronizes to the Master via the Ethernet link. Time difference between its clock and the Master’s clock, after synchronization, is in the order of 100 nanoseconds, thus indicating a normal successful time synchronization. However, the results of the TSN device 2 synchronization show a lower accuracy. Figure 3 shows the clock time differences of the Master clock (Red line) and TSN device 2’s clock (Blue line) to the true time. (True time is the actual simulation time and all the nodes in simulation, including TSN Master, have a constant drift.) It can be seen that the difference between TSN Master graph and TSN device 2 graphs is approx. 2.5 milliseconds, which means that after synchronization TSN device 2 still have 2.5ms difference from the Master’s clock time. This low accuracy is explained by figure 4. Figure 4 (a) shows the uplink propagation time, downlink propagation delay, and their difference. The 802.1AS standard assumes symmetric link in terms of propagation delay and computes the average propagation delay, which is used for synchronization. But with a 5G network, the uplink and downlink propagation delay is asymmetric, mainly because of the differences in the medium access control (MAC) for uplink and downlink traffic, resulting in error in propagation delay computation, which in turn affects the accuracy of synchronization.

Figure 4 (b) shows the box plot of the uplink and downlink delay as well as the actual propagation delay calculated by the 802.1AS model. From Figure 4 it can be seen that the maximum difference between uplink and downlink propagation delay is approx. ~ 2ms. If this difference is considered in the propagation delay calculation, the time difference between TSN device 2 and the Master, after synchronization, reduces to ~ 0.4 ms at maximum (see Figure 3 – TSN device 2 clock time (adjusted)), which is still quite high. The variability of the time difference can be explained by the variability of the uplink and the downlink propagation delay, as seen in figure 4.

Figure 3. Time differences to the true time after synchronization.

Figure 3. Time differences to the true time after synchronization.

The reason for propagation delay differences in uplink and downlink is the process of how 5G UE gets access to channel for uplink transmissions. The UE can only transmit in the uplink when the channel grants are given to the UE, resulting in longer delays which in turn results in asymmetric uplink and downlink propagation delay. Furthermore, QoS support is also absent in Simu5G framework, which further reduces the accuracy during synchronization since sync messages can not be tagged as high priority messages.

5.2. Simulation Scenario 2

In simulation scenario 2, the TSN Switch synchronizes to the GM via the Ethernet link and forwards the synchronization frames to the TSN device 2. The TSN device 2 moves from the left to the right side of the simulation area as shown by the mobility direction arrow in figure 2 (b). During the movement, a handover from gNodeB1 to gNodeB2 takes place.

Figure 4. (a) Uplink and Downlink propagation delay during PDelay Measurement; (b) 802.1AS calculated PDelay compared to Uplink and Downlink Propagation delay during the synchronization process.

Figure 4. (a) Uplink and Downlink propagation delay during PDelay Measurement; (b) 802.1AS calculated PDelay compared to Uplink and Downlink Propagation delay during the synchronization process.

Figure 5 (a) shows the time differences of the TSN Master and TSN device 1 clock to the true time for the first 5 seconds of simulation. The time difference after synchronization is in order of 100 nanoseconds, indicating a successful synchronization, as expected due to the direct 1Gbps Ethernet link between them. Figure 5 (b) shows the true time differences of the TSN Master and the TSN device 2 after synchronization. The handover event at around 95 seconds is clearly visible, as the difference of the TSN device 2 to the true time suddenly increases to 50 ms and the difference between TSN Master and TSN device 2’s clocks is approx. 46ms. The true time differences of TSN Master and TSN device 2 before and after the handover event are also higher than the true time differences of the TSN Master and the TSN device 1. This is (like in scenario 1) due to uplink and downlink propagation delay differences. The main reason for the multiple, shorter than the highest delay difference peaks, after the handover are Layer 2 retransmissions between gNodeB and TSN device 2. Since the TSN device has just entered the coverage area of gNodeB2, therefore L2 retransmissions of erroneous frames causes multiple smaller peaks, which disappear when the device reaches closer to gNodeB2.

Propagation delays in uplink and downlink direction are shown in figure 6. An asymmetry regarding the uplink and downlink delays can be observed (similar to simulation scenario 1) as well as delay variations (caused by L2 retransmissions in 5G network), resulting in increased inconsistency of PDelay in its measurement. This in turn leads to a significant time difference between the TSN device 2 and the TSN Master after synchronization. The downlink and uplink delay asymmetry still remains in the simulation as discussed in previous section, and it is often pronounced due to retransmissions, e.g., in figure 6 (a) between 150s – 250s. Eventually, if in the PDelay calculation the difference of uplink and downlink delay is considered, the average time difference between TSN device 2 and TSN Master reduces to be around 500 microseconds with some irregularities during handover and retransmissions.

Figure 5. Time differences to the true time after synchronization for TSN Master and (a). for TSN device 1. (b). for TSN device 2.

Figure 5. Time differences to the true time after synchronization for TSN Master and (a). for TSN device 1. (b). for TSN device 2.

A possible solution to avoid synchronization errors during handover is to halt the time synchronization process during the handover process, since synchronizing during handover results in false clock time for the slaves. Once the handover is completed, synchronization process can be started again with the new Sync and PDelay calculation frames.

Figure 6. (a) Uplink and Downlink propagation delay during PDelay Measurements; (b) 802.1AS calculated PDelay compared to Uplink and Downlink Propagation delay during synchronization process (outliers excluded).

Figure 6. (a) Uplink and Downlink propagation delay during PDelay Measurements; (b) 802.1AS calculated PDelay compared to Uplink and Downlink Propagation delay during synchronization process (outliers excluded).

The findings from both simulations align with the results that were achieved by [1] & [2], as mentioned in section 3.

6. Conclusion

Asymmetry in uplink/downlink propagation delay can adversely affect the synchronization process (because of the PDelay calculation which assumes symmetry). Furthermore, changing radio conditions and the uplink medium access mechanism (which uses uplink grants) in 5G network, and Layer 2 retransmissions might result in large differences between uplink and downlink delay. Since the PDelay calculation (in 802.1AS) assumes uplink/downlink symmetry and averages the propagation delay in uplink and downlink direction, any delay asymmetry leads to time synchronization errors. Thus, the need for PDelay correction, before synchronization takes place, arises.

The main challenges, at the moment, in TSN over 5G Systems is asymmetric uplink and downlink delay, delays due to handover, QoS mappings from TSN to 5G, and retransmissions. For further research, we plan to focus on reducing propagation delay errors due to asymmetric uplink and downlink by averaging previous n uplink or downlink delay values instead of averaging up/downlink delay values for a specific synchronization cycle. Furthermore, we also plan to simulate synchronization in uplink (UE as a GM and a slave connected to the 5GS core) and synchronization between multiple UEs (multiple UEs synchronizing to a GM UE).