DHL: Dynamic History Length for Packet Order Recovery in Time-Sensitive Networks

DHL: Dynamic History Length for Packet Order Recovery in Time-Sensitive Networks How-Hang Liu ∗, Hosein K. Nazari ∗, Tobias Scheinert ∗, Stefan Senk ∗, Giang T. Nguyen †, Frank H. P. Fitzek ‡ ∗Deutsche Telekom Chair of Communication Networks, TU Dresden, Germany †Chair of Haptic Communication Systems, TU Dresden, Germany ‡Centre for Tactile Internet with Human-in-the-Loop (CeTI), TU Dresden, Germany E-mails: {firstname.lastname}@tu-dresden.de∗†‡ Abstract—The integration of 6G and Time-Sensitive Networking (TSN) is desired to provide both mobility and deterministic communication. In TSN, Frame Replication and Elimination for Reliability (FRER) improves stream resilience using redundant paths. However, the original FRER with a fixed history length is ineffective when facing variable-delay links that cause reordering and bursty arrivals of packets. We propose the Dynamic History Length (DHL) algorithm that dynamically adjusts the FRER elimination buffer based on real-time link delay measurements. We implement and evaluate DHL in OMNeT++/INET, which provides a comprehensive and high-accuracy model of TSN switches. We compare DHL with the FRER variations. In a 100 ms dual-link simulation with latency ramps and a 10 ms outage, DHL reduces duplicate packet deliveries by 39 % compared to baseline. In terms of the 99th percentile inter-arrival intervals, DHL shows an improvement of 4.3 ms compared to the sorting and shaping algorithm, allowing it to better match the sender’s 1 ms transmission interval. Index Terms—Time-Sensitive Networking (TSN), Frame Replication and Elimination for Reliability (FRER), OMNeT++ I. INTRODUCTION The advent of 6G [1] has transformed the industrial landscape, driving Industry 4.0 innovations by enabling new use cases and revenue streams beyond traditional consumer markets. Emerging applications, such as flexible manufacturing and robotics [2], demand ultra-low latency, deterministic communication, and high reliability to ensure seamless operation. To meet these stringent requirements, the integration of 6G mobile communication with TSN [3] has emerged as a promising solution, combining the mobility of wireless 6G networks with the deterministic guarantees of TSN. This synergy offers significant benefits for novel use cases but remains an open research problem due to the challenges of maintaining end-toend synchronization and reliability across heterogeneous wired and wireless domains. TSN, originally designed for wired networks, provides deterministic communication through standards such as IEEE 802.1CB, which implements FRER [4]. FRER enhances reliability by duplicating frames across redundant links at a duplication node and eliminating duplicates at an elimination node, as illustrated in Fig. 1. This mechanism ensures robust delivery in wired TSN environments, such as industrial control systems. However, extending TSN principles to 6G networks introduces significant challenges. In 6G-TSN scenarios, where the 6G network acts as a virtual link within the TSN domain, wireless channels introduce unpredictable delays and potential disconnections. These variations can significantly impair the effectiveness of FRER, as delayed or lost frames disrupt the elimination process, leading to packet loss or unintended duplication that can degrade application performance. A common approach to mitigate delayed or lost frames in TSN systems is to employ larger buffers at switches to maintain an extended history of sequence numbers. While this strategy can improve reliability by accommodating delayed frames, it requires costly hardware upgrades and increases processing times due to larger history lengths, which may compromise the stringent latency requirements of 6G-TSN applications. Furthermore, the literature highlights additional challenges with FRER, including issues with frame reordering and burst transmission under certain conditions [5]–[7], exacerbating the complexity of ensuring deterministic communication in 6GTSN environments. To tackle these issues, we propose a novel FRER elimination algorithm, namely DHL. DHL dynamically adjusts the history length in the buffer on the fly, only increases the length when it is absolutely required. To precise adjustment of the history length DHL continuously measure link conditions regarding delay. Optionally, DHL can imcorporate sorting and shaping functions at the elimination node. These mitigate frame reordering and burst transmission [5]–[7]. We integrated the algorithm into OMNeT++ by extending a TSN module. This enables efficient 6G-TSN system evaluation. We validated it using literature-based scenarios [7]. These included varying link delays and simulated link failures. Our results show reduced duplication rates 39 %. They also indicate fewer out-of-order frames and less receiving jitter with the reduction rates 40 % and 35 %, respectively. To facilitate replicating the proposed DHL in future research we have extended the open-source toolkit in OMNeT++ ©2025 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Sender Receiver Switch 1 Switch 2 Sequence Recovery Function (SRF) Sequence Generation Function Fast Path Slow Path 123 1' 2' 3' TPID (2 bytes) Reserved (2 bytes) SeqNum (2 bytes) R-Tag 1 2 3 Fig. 1. This figure illustrates the integration of a next-generation mobile network with TSN. It highlights a basic FRER workflow: the duplication node add tags and duplicates each packet using a sequence-generation mechanism, while the elimination node applies sequence-recovery logic to identify and discard any duplicate packets. and released the source code for the research community: https://github.com/TUDComnetsTSN/FRER_sorting_shaping. II. BACKGROUND AND RELATED WORK In this section, we will provide a brief overview of the common algorithms utilized in the Sequence Recovery Function (SRF). Next, we highlight the scenarios that lead to the cracks in FRER, specifically focusing on reordering and burst transmission. Following that, we present a general perspective on the current research focuses related to 5G and FRER, as well as the existing implementations of FRER in OMNeT++. As shown in Fig. 1, the sequence generation function attaches a 6-byte redundancy tag (R-tag) to the 802.1Q header. The TPID is 0xF1C1 [4], with a reserved field for future use. The last 2 bytes hold the sequence number, identical for duplicate packets. The SRF can use either the Match Recovery Algorithm (MRA) or Vector Recovery Algorithm (VRA) to remove duplicate packets by sequence number. This paper focuses solely on the MRA; the VRA is out of scope. The fundamental concept of MRA is illustrated in Fig. 2. The MRA primarily stores the highest sequence number received and compares it with the next incoming sequence number. If the incoming number matches the highest sequence number, the MRA discards the duplicate packets; otherwise, it forwards the packets as usual [4]. For example, as shown in Fig. 2, the sender transmits packets at regular intervals. It is important to note that port 1 is connected to a faster link, while port 2 experiences greater delays. At time unit 2, the MRA receives both packet 1 and packet 1’ from the different ports, successfully eliminating the duplicate. Similarly, at time unit 8, another duplicate elimination occurs for the packet with sequence number 4. However, the MRA is limited when packets experience large delays. For instance, at time unit 5, the highest sequence number acknowledged is 4. If packet 2’ arrives late from the slower path, the MRA will not discard it, as it is still considered Sender Ingress port 1 Ingress port 2 MRA (Length 2) Egress port 3 1Time Unit 2 3 4 5 6 7 8 9 10 11 1 2 3 4 5 7 8 9 10 11 1234567 8910 Packets Lost 1' 2' 3' 4' 5' 1 1' 123 Eliminate Duplicate 2 3 4 2' 4 2' 4 3' 3' 4 4' Eliminate Duplicate 7 5' 8 6' 9 7' 7 5' 8 6' 9 7' 10 BurstDuplicate 6' 7' 6 Fig. 2. Illustration of the MRA algorithm in FRER. Ingress ports 1 and 2, along with Egress port 3, correspond to the ports on switch 2 depicted in Fig. 1. Ingress ports 1 and 2 are connected to the fast link and slow link, respectively. Egress port 3 is after the operation of MRA and is connected to the receiver. We index original packets by iand denote their duplicates by i′. valid despite the fact that packet 2 was already accepted at time unit 2. A further challenge arises for both MRA and VRA [5]– [7] when the fast link experiences packet loss and subsequent recovery, causing valid sequence numbers to be received and forwarded from both the fast and slow links. As observed at time units 9 and 10, after the SRF, the sequence numbers forwarded by the egress port are out of order (5’, 8, 6’, 9). In this scenario, the egress port forwards a burst of packets. Originally, the sender transmitted one packet per time unit, but now two packets arrive in a single time unit. This occurs because some packets (5, 6) are lost on the fast link, and their duplicate packets (5’, 6’) are eventually received from the ingress port 2, higher sequence number packets (8, 9) continue to arrive from the ingress port 1 simultaneously. As a result, valid packets from both ingress ports may be accepted within the same time unit. Note that the burst and disorder situation of VRA in the figure did not occur; however, if the history length reaches 4, then the burst issue will arise. Research on integrating 5G/6G with FRER can be grouped into two main directions. The first direction includes building a real hardware testbed for various use case scenarios, such as autonomous mobile robots [8], milling process applications [9], and oilfield operations in petrochemical contexts [10]. The second direction includes designing scheduling algorithms for selecting and routing traffic across multiple redundant paths. Such algorithms, for example, can be applied in space–terrestrial networks [11] or in-vehicle networks [12]. In addition to developing testbeds and designing scheduling algorithms, Aijaz [13] has implemented a simulation approach to evaluate FRER with 5G. This research focuses specifically on the 5G domain, discussing duplication and elimination points across various 5G components and protocol layers. Unlike the previously mentioned studies, our focus is specifically on recovery algorithms for FRER. To the best of our knowledge, the only study addressing issues in FRER recovery algorithms is [7], which applies network calculus on abstract models to evaluate the worst-case impact of adding sorting and shaping functions after the elimination function. However, the presented approach is based on a fixed history length and lacks detailed implementation guidance. Furthermore, its shaping function relies on ATS, which is rarely implemented in commercial hardware due to its complexity. Regarding the OMNeT++ with the FRER implementation, only a few studies have been conducted in this area [5], [14], and both were released before the official introduction of FRER functionality in the OMNeT++ INET library. One study implemented FRER in OMNeT++ with control-plane capabilities [14], while another identified issues in FRER protocols but did not address bursty or reordered transmissions [5]. In summary, this work focuses on the algorithm in the SRF to reduce the acceptance of duplicate packets. Moreover, we implemented the sorting and shaping algorithm after the SRF to address the disorder and burst transmission problems, based on the mainline release of the OMNeT++ INET library for FRER. III. DHL – DYNAMIC HISTORY LENGTH The buffer needs to store batches of packets to reorder them and eliminate duplicated packets. The buffer’s history length has to meet two design constraints. To minimize latency, the history length of the buffer has to be minimized. However, short history lengths are insufficient to accommodate packets from different links with large latency discrepancies, increasing the likelihood of duplicate packets. The DHL introduces the idea of variable history length for the buffer. DHL algorithm continuously measures the latency that each packet experiences from various links and adjusts the history length according to the discrepancies between their latencies. A. Dynamic History Length As shown in Algorithm 1, DHL considers the latency of measurement links. When there are significant latency differences between the links, the likelihood of accepting a duplicate sequence number increases. As a result, we need to extend the history length. Conversely, if the differences are smaller, we can reduce the history length. If this feature is enabled, the algorithm is executed every τ seconds to update the history length. In line 2, we compute the observed delay difference between the links, and in line 3, translate this span into the required window size according to the formula in [5], where ˆ Bis the proposed new length of the history window W. Line 4 enforces a minimum capacity of two, and lines 5–8 then adjust the history length B. If the updated ˆ Bis smaller then B, then we reduce the value smoothly by considering the average of the updated ˆ Band previous value Bin line 7. Otherwise, line 7 grows immediately by assigning B←ˆ B. Finally, lines 10–11 prune the existing sliding window Wdown to the updated capacity by repeatedly calling removeFront(W)until |W| ≤ B. Algorithm 1: Dynamic History Length Input : B,W: current history window of stored sequence numbers, minDelay,maxDelay: observed link-delay extremes, J: Jitter, ∆t: sender’s inter-packet interval (ms), τ: timer interval Output: updated window capacity B, pruned history window W 1Every τseconds (timer event): 2δ←(maxDelay −minDelay) + J// delay span 3ˆ B← ⌈(δ×10−3)/∆t⌉// needed slots 4if ˆ B < 2then 5ˆ B←2// enforce min window of 2 6if ˆ B < B then 7B← ⌊(B+ˆ B)/2⌋// smooth shrink 8B←ˆ B// grow immediately 9if |W|> B then 10 while |W|> B do 11 removeFront(W) B. Integration of DHL into OMNeT++ The current OMNeT++ INET (4.5.4) FRER implements an extended MRA, which is a duplicate filtering mechanism using a sliding window Wof fixed history length B. For each incoming packet, it checks whether the packet’s sequence number is already in the window. If it is, the packet is dropped; otherwise, the sequence number is added to the window. If the window exceeds its size limit, the oldest entry is removed. Accepted packets are then forwarded. The core de-duplication logic is implemented in the StreamMerger module. We extend this functionality in the StreamMergerSorter module to support adaptive buffering and in-order packet shaping. Three boolean parameters control these features: dynamicBuffersize enables the buffer update logic in Algorithm 1, enableReordering activates the sorting algorithm, and periodicEmission enables both sorting and shaping. Two timing parameters govern the timing behavior: timerInterval (τ) triggers the mergerTimer self-message for buffer updates during initialization, while senderTransmissionInterval sets the interval for the releaseTimer, which controls transmission timing in the shaping process. Link delays are measured by timestamping each packet at Switch1, using the reserved field in the R-Tag inserted by IEEE8021rTagEpdHeaderInserter. These timestamps are then read by StreamMergerSorter at Switch2. During each mergerTimer event, handled in the handleMessage function, we run Algorithm 1 to adjust and prune the history length. We override the pushPacket function to implement the sorting algorithm. Duplicate detection and dropping are first TABLE I LINK DELAY PHASES OVER TIME Time (ms) Fast Link Slow Link 0–9 0 ms 0 ms 10–19 0 ms ramps 1 →10 ms in 1 ms steps 20–29 0 ms holds at 10 ms 30–39 0 ms ramps 11 →20 ms in 1 ms steps 40–49 0 ms holds at 20 ms 50–59 down (∞) holds at 20 ms 60–69 0 ms ramps 20 →10 ms in 1 ms steps 70–79 0 ms holds at 10 ms 80–89 0 ms ramps 9 →0 ms in 1 ms steps 90–100 0 ms 0 ms handled by delegating to StreamMerger. If enableReordering is set to true, the function either buffers out-of-order packets or forwards the next expected packet, incrementing its counter. Afterward, the emitInOrder function is called to perform shaping. If periodicEmission is true,emitInOrder schedules the releaseTimer to trigger after senderTransmissionInterval, pacing packet delivery to match the sender’s transmission rate. IV. EXPERIMENT SETUP This section presents the experimental setup for DHL, beginning with the evaluation scenario, followed by the key measurement metrics and simulation settings. A. Simulation Setup and Link Behavior The simulation topology adheres to the straightforward structure illustrated in Fig. 1 with two Ethernet links between Switch1 and Switch2. We emulate lossy wireless links by using two parallel Ethernet connections between Switch 1 and Switch 2, whose latencies and outages are driven by the ScenarioManager (configured via an XML file). Our testing scenario consists of a total simulation time of 100 ms, during which the sender transmits packets periodically at 1 ms intervals ∆tthrough two physical links. The conditions of these links are described in Table I. For the fast link, the connection remains stable but experiences a breakdown for 10 ms in the middle of the simulation. In contrast, the slow link’s latency increases and remains at a plateau for two phases until it reaches 20 ms. After that, the latency decreases in two phases until it ultimately reaches zero. According to our design scenario, we set Jequals 10 ms, representing the empirically measured one-way delay variation observed on the link. B. Performance Metrics History length is considered as main performance metric as it influences both the Duplicate Ratio (Dup) and the Outof-Order Ratio (OoO). The Dup measures the percentage of packets whose sequence numbers match those seen earlier (i.e., duplicates). Meanwhile, the OoO quantifies the fraction of adjacent packet pairs whose sequence numbers do not increment by exactly one. In the specific case discussed in Section II, the out-of-order issue cannot be avoided solely through the 012345678910 Jitter (ms) 0 20 40 60 Ratio (%) Baseline OoO. Baseline Dup. DHL OoO. DHL Dup. Sorting OoO. Sorting Dup. Fig. 3. The out-of-order ratio and duplicate ratio are presented. Since the results from the sorting plus shaping algorithm are the same as those from the sorting algorithm, we did not include them in this plot. The Jitter Jis only used in the DHL. use of history length. Therefore, we also require an additional buffer, referred to as the sorting buffer, to ensure in-sequence transmission. We will also present the length of the sorting buffer in our measurements. Finally, the inter-arrival interval is a critical metric that highlights the benefits of our shaping feature in mitigating burst transmissions. V. EVALUATION RESULTS In this section, we examine the performance of various algorithms. A. Impacts on In-order Delivery In Fig. 3, we present the out-of-order and duplicate ratios comparison between different algorithms, including baseline, our proposed DHL, sorting, and sorting plus shaping. The baseline configuration uses the default MRA algorithm with a fixed history length of 5. The value of Jin the DHL algorithm significantly influences performance, as it directly affects the history length. An increase in Jleads to a reduction in both the OoO and the Dup. In contrast, the other algorithms, which do not utilize J, maintain constant ratios. When Jis set to 10 ms, our proposed DHL algorithms demonstrate a notable improvement in the Dup, reducing it from 39 % to 0 % compared to the baseline algorithm. Additionally, the out-of-order ratio decreases from 61 % to 21 % when compared to the baseline. However, when Jis below 5 ms, the performance of the DHL algorithm is inferior to the baseline. This decline occurs because, during the first 10 ms of the simulation, the packet delays do not differ, which leads to the DHL algorithm updating the history length to less than five. As a result, the algorithm struggles to eliminate duplication effectively. The sorting algorithm achieves both an OoO and Dup of 0 % due to its strict tracking of sequence numbers. Since the sorting plus shaping algorithm yields the same results as the sorting method, we did not include it in our comparison. In addition, the sorting and sorting plus shaping algorithms can further decrease both the OoO and the Dup to zero. The primary aim of these algorithms is to ensure that packets are 10 210 1100101 Interval (ms) 0.0 0.2 0.4 0.6 0.8 1.0 Empirical CDF Baseline DHL Sorting Sorting+Shaping Fig. 4. The empirical cumulative distribution function (ECDF) for interarrival intervals at the receiver is used to compare the performance of the four algorithms. forwarded in order. Since both the sorting and sorting plus shaping algorithms yield the same zero results, we have only presented the results for the sorting algorithm here. B. Impacts on Latency Fig. 4 illustrates the packet inter-arrival intervals for various algorithms. The expected inter-arrival rate is 1 ms, which highlights the advantage of the sorting plus shaping algorithm, as it maintains most packets within the 1 ms interval. In contrast, the other algorithms experience burst transmissions. Notably, the DHL algorithm outperforms the sorting algorithm by transmitting fewer bursty packets. This observation indicates that approximately 10 % of packets from the DHL algorithm and around 20 % from the sorting algorithm have inter-arrival intervals of less than 1 ms. To illustrate the extent of large outliers, we report the 99th percentile (P99) of inter-arrival intervals. This P99 indicates the maximum interval below which 99 % of all packets arrive. The measured P99 values are as follows: Baseline at 2.0 ms, DHL at 1.3 ms, Sorting at 1.6 ms, and Sorting with Shaping at 5.6 ms. Notably, DHL shows a 35 % reduction compared to the Baseline. However, there is a 10 ms tail due to a disruption in the fast link, during which the next valid packet is received only after the link resumes. Additionally, both the sorting and sorting with shaping algorithms exhibit a 20 ms tail because they buffer out-of-order packets until the sequence number is correctly incremented. C. Behavior of History Length Dynamics Fig. 5 illustrates the link delay (right y-axis) derived from the StreamMergerSorter module in Switch 2. The link delay corresponds to our configuration outlined in Table I. The nearly zero values result from packets received over the fast link, while the two phases of increasing and decreasing delays originate from the slow link. It’s important to note that during simulation time from 60 ms to 70 ms , there is a gradual reduction in latency from 20 ms to 10 ms. This results in earlier packets experiencing higher delays, while later packets face lower delays, with both arriving simultaneously at the 80 ms mark. 0 10 20 30 40 50 60 70 80 90 100 Time (ms) 0 10 20 30 40 Size Link delay (ms) Baseline DHL Sorting Sorting+Shaping 0 10 20 30 40 Latency (ms) Fig. 5. This figure displays the link delay received from the algorithms, along with the history length from the baseline and DHL algorithms. Additionally, it shows the buffer size for the sorting and sorting plus shaping algorithms. The baseline history length is set to 5, and the DHL tracks the link delay differences with an update frequency of 10 ms. As the latency of the slow link increases, the history length also increases. It is important to note that between 50 ms and 60 ms of the simulation time, the fast link fails. Consequently, the packets are then only coming from the slow links, which leads to a reduction in the latency difference observed in the packets. As a result, the DHL decreases in the following 10 ms, from 60 ms to 70 ms of simulation time. Additionally, Fig. 5 provides information about the buffer size, as both the sorting and sorting plus shaping algorithms create a new buffer to store out-of-order packets. Starting at 60 ms into the simulation, both algorithms buffer the out-oforder packets. The sorting algorithms subsequently forward these packets in a burst around 80 ms. In contrast, the sorting plus shaping algorithm releases packets at the same rate as the sender’s transmission interval. At the same time, it receives higher sequence numbers and stores the packets in the buffer. As a result, the buffer for the sorting plus shaping algorithm remains stable. In summary, we can see that the history length adapts according to the link latency and the usage of buffer size in the sorting and sorting plus shaping algorithms in Fig. 5. D. Impacts on Packet Sequence In Fig. 6, the evolution of the sequence number over time during the simulation is shown. This provides insights into how different algorithms handle the sequence number, including the elimination of duplicates, waiting for the correct sequence number to arrive, and the smooth release of packets. Since the sender’s transmission interval is 1 ms, the sequence number should ideally increase by one every 1 ms during the simulation. The baseline algorithm starts accepting outof-order packets after 20 ms because its history length of 5 is insufficient to handle late-arriving packets with lower sequence numbers. This limitation results in frequent "teeth" patterns in the baseline algorithm. The DHL algorithm addresses most of these out-of-order issues, but between 70 ms and 80 ms, it still struggles. This is because original packets (not duplicates) coming from both fast 0 10 20 30 40 50 60 70 80 90 100 Time (ms) 0 20 40 60 80 100 Sequence Number Baseline DHL Sorting Sorting+Shaping Fig. 6. This figure illustrates how the sequence number changes over time, detailing the operational behaviors of different algorithms. and slow links need to be accepted and forwarded. Introducing a sorting algorithm allows the system to buffer sequence numbers from 60 ms until nearly 80 ms, at which point it releases the buffered packets in a burst once it receives the packets that arrived before 60 ms in sequence. Similarly, the sorting plus shaping algorithm releases the sorting buffer at an interval of 1 ms, in line with the sender’s transmission interval. This helps mitigate the burst transmission issue. VI. CONCLUSIONS AND FUTURE DIRECTIONS This study introduced DHL, an enhanced FRER elimination algorithm, that jointly adapts its history length sliding window based on live link-delay measurements. Additionally, we implement a state-of-the-art algorithm for strict sequencing via sorting and shaping. Our OMNeT++/INET extension transparently augments the existing StreamMerger module, enabling on-the-fly history length resizing, out-of-order packet buffering, and paced emission without altering existing FRER primitives in INET. In evaluation scenarios with dynamic latency ramps on the slow-links until 20 ms and a 10 ms fast-link outage, our DHL alone reduced duplicate frames and out-of-order frames by 39 % and 40 %, respectively. Additionally, DHL outperforms the sorting and shaping algorithm regarding the 99th percentile of inter-arrival intervals, which is 1.3 ms compared to 5.6 ms. This demonstrates the advantage of DHL in limiting jitter to the sender’s 1 millisecond pacing. This work paves the way for exploring multi-stream FRER, hardware-aware trade-offs, and 6G scheduling integration [15]. Next steps include prototyping on SmartNICs, adding multiflow prioritization with shaping, and testing under realistic 6G–FRER traffic [16], [17]. By releasing our source-code https://github.com/TUDComnetsTSN/FRER_sorting_shaping, we aim to support and advance community efforts toward achieving deterministic, reliable communications in the 6G–TSN era. ACKNOWLEDGMENT This work was funded by the German Federal Ministry for Economic Affairs and Climate Action (BMWK), projects “TICCTEC” – grant 01MC22007A, “5G-OPERA” – grant 01MJ22008A, and “stic5G” – grant 01MJ22018C, and by the German Research Foundation (DFG, Deutsche Forschungsgemeinschaft) as part of Germany’s Excellence Strategy – EXC 2050/1 – Project ID 390696704 – Cluster of Excellence “Centre for Tactile Internet with Human-in-the-Loop” (CeTI) of Technische Universität Dresden. REFERENCES [1] P. Schwenteck, G. T. Nguyen, H. Boche, W. Kellerer, and F. H. P. Fitzek, “6G perspective of mobile network operators, manufacturers, and verticals,” IEEE Netw. Lett., vol. 5, no. 3, pp. 169–172, 2023. [2] H. K. Nazari, J. Abicht, S. Senk, H.-H. Liu, T. Scheinert, G. T. Nguyen, and F. H. P. Fitzek, “Bridging the gap: 5G-TSN integration for industrial robotic communication,” in Proc. Eur. Wireless Conf., 2023, pp. 102–109. [3] K. Zanbouri, M. Noor-A-Rahim, J. John, C. J. Sreenan, H. V. Poor, and D. Pesch, “A comprehensive survey of wireless time-sensitive networking (TSN): Architecture, technologies, applications, and open issues,” IEEE Commun. Surveys Tuts., pp. 1–1, 2024. [4] IEEE Standards Association, IEEE Standard for Local and Metropolitan Area Networks—Frame Replication and Elimination for Reliability, IEEE Std. IEEE Std 802.1CB-2017, 2017. [5] L. Maile, D. Voitlein, K.-S. Hielscher, and R. German, “Ensuring reliable and predictable behavior of IEEE 802.1CB frame replication and elimination,” in Proc. IEEE ICC, 2022, pp. 2706–2712. [6] R. Hofmann, B. Nikoli´ c, and R. Ernst, “Challenges and limitations of IEEE 802.1CB-2017,” IEEE Embed. Syst. Lett., vol. 12, no. 4, pp. 105– 108, 2020. [7] L. Thomas, A. Mifdaoui, and J.-Y. Le Boudec, “Worst-case delay bounds in time-sensitive networks with packet replication and elimination,” IEEE/ACM Trans. Netw., vol. 30, no. 6, pp. 2701–2715, 2022. [8] J. Ansari, T.-s. Hsiao, M. H. Jafari, B. Varga, J. Farkas, I. Moldován, A. Göppert, and R. H. Schmitt, “5G enabled flexible lineless assembly systems with edge cloud controlled mobile robots,” in Proc. IEEE PIMRC, 2022, pp. 1419–1424. [9] P. E. Kehl, J. Ansari, M. Lovrin, P. Mohanram, C.-C. E. Liu, J.-L. L. Yeh, and R. H. Schmitt, “5G-TSN integrated prototype for reliable industrial communication using frame replication and elimination for reliability,” Electronics, vol. 14, no. 4, 2025. [Online]. Available: https://www.mdpi.com/2079-9292/14/4/758 [10] J. Gu, T. Chen, Y. Lu, X. Wu, and R. Wang, “Optimizing frame replication and elimination for reliability (FRER) protocol with pigeoninspired optimization algorithm,” in Proc. ICAIRC, 2024, pp. 842–846. [11] G. Peng, S. Wang, T. Huang, F. Li, K. Zhao, Y. Huang, and Z. Xiong, “Fastts: Enabling fault-tolerant and time-sensitive scheduling in spaceterrestrial integrated networks,” IEEE J. Sel. Areas Commun., vol. 42, no. 12, pp. 3551–3565, 2024. [12] A. A. Syed, S. Ayaz, T. Leinmüller, and M. Chandra, “Fault-tolerant dynamic scheduling and routing for TSN-based in-vehicle networks,” in Proc. IEEE VNC, 2021, pp. 72–75. [13] A. Aijaz, “5G replicates TSN: Extending IEEE 802.1CB capabilities to integrated 5G/TSN systems,” in Proc. IEEE CSCN, 2024, pp. 108–112. [14] D. Ergenç and M. Fischer, “Implementation and orchestration of IEEE 802.1CB FRER in OMNeT++,” in Proc. IEEE ICC Workshops, 2021, pp. 1–6. [15] H. K. Nazari, M. A. Kurt, H.-H. Liu, S. Senk, G. T. Nguyen, and F. H. P. Fitzek, “Incremental joint scheduling and routing for 5G-TSN integration,” in Proc. Eur. Wireless Conf., 2023, pp. 110–116. [16] H.-H. Liu, S. Senk, M. Ulbricht, H. K. Nazari, T. Scheinert, M. Reisslein, G. T. Nguyen, and F. H. P. Fitzek, “Improving TSN simulation accuracy in OMNeT++: A hardware-aligned approach,” IEEE Access, vol. 12, pp. 79 937–79 956, 2024. [17] S. Senk, T. Scheinert, H. K. Nazari, H.-H. Liu, G. T. Nguyen, and F. H. P. Fitzek, “5G-TSN flextac: Experience a new touch,” in Proc. IEEE INFOCOM WKSHPS, 2024, pp. 1–3.