V-TSN: A Software-Defined TSN Overlay for General-Purpose Networks Mohammadparsa Karimi1 , Majid Nabi1 , Ahmed Khalaf2 , Andrew Nelson1 , Kees Goossens1 , Twan Basten1
arXiv:2606.28285v1 [cs.NI] 26 Jun 2026
1
Department of Electrical Engineering, Eindhoven University of Technology, The Netherlands Emails: {m.karimi, m.nabi, a.t.nelson, k.g.w.goossens, a.a.basten}@tue.nl 2 Architecture and Network Solutions, AUMOVIO, Germany Email: [email protected]
Abstract—Time-Sensitive Networking (TSN) extends Ethernet with deterministic communication for time-critical applications such as industrial automation, in-vehicle networks, and cyberphysical systems. However, realizing TSN behavior without dedicated hardware is difficult. During design and validation, offline simulation cannot run application software at real-time speed when costly specialized TSN hardware is not (yet) available. At deployment time, many systems run on general-purpose and cloud networks with no native TSN support, where provisioning full TSN hardware is unnecessary or impractical for applications that tolerate relaxed timing. In this paper, we introduce Virtual Time-Sensitive Networking (V-TSN), a software-defined overlay that realizes gPTP-based synchronization and TSN traffic shaping over general-purpose, non-deterministic networks without specialized hardware. V-TSN runs in real time alongside the unmodified application stack, serving both as a development-time emulation tool and as a cost-efficient deployment option where relaxed timing is acceptable. In a cloud-based deployment, VTSN achieves an average clock offset below 200 microseconds, it isolates time-critical traffic through a virtual Time-Aware Shaper (TAS), and it enforces per-class bandwidth reservations through a virtual Credit-Based Shaper (CBS). Index Terms—Time-Sensitive Networking, Virtual TSN, Network Function Virtualization, Software-Defined Networking
I. I NTRODUCTION Time-Sensitive Networking (TSN) [1] is a set of IEEE 802.1 standards that extend Ethernet with deterministic communication, enabling time synchronization, bounded latency, low jitter, and high reliability for time-critical distributed systems. It integrates functionalities such as precise time synchronization [2], Time-Aware shaper (TAS) [3], CreditBased Shaper (CBS) [4], and frame preemption [5] to enable predictable data exchange over standard Ethernet. TSN is a key enabling technology across domains such as industrial, invehicle, aerospace, and robotic, where distributed components must operate in tight coordination based on a shared notion of time to ensure correctness, safety, and reliability [6]. Modern distributed systems are increasingly deployed on commodity and virtualized platforms, where applications run as virtual machines or containers on nodes ranging from edge platforms to on-chip systems. These nodes are typically interconnected through general-purpose networks such as the Internet or cloud infrastructures, which provide neither deterministic communication nor native TSN capabilities [7]. In such environments, clocks are at best loosely synchronized
through software protocols such as NTP, or not synchronized at all, and there is no synchronized TSN protocol stack, no deterministic forwarding, and no time-aware traffic shaping. Achieving genuine TSN determinism and TSN-grade synchronization on these platforms requires specialized hardware, such as TSN-capable network interfaces and switches with hardware timestamping, which significantly increases system cost and deployment effort [8]. This level of precision, however, is not always necessary; in many practical scenarios, moderate timing accuracy is sufficient for correct system behavior [9]. Beyond cost, faithfully reproducing TSN behavior during development and validation is itself challenging, particularly because in early design stages the target TSN hardware is often not yet available. Thus, validation must be carried out on virtual platforms rather than on the final infrastructure. This is especially evident in domains such as automotive [10] and aerospace [11], where extensive validation is performed in virtual environments before integration into physical systems and where timing behavior is critical for correct and safe operation. Simulation-based tools [12], [19] support offline design and analysis of TSN systems, but they run in simulated time, far slower than real time, and cannot execute the actual application software. They therefore cannot reproduce the runtime behavior of a complete system over real distributed infrastructure, which is what is needed to validate timing interactions and functional correctness prior to deployment. To address the cost and flexibility limitations of hardwarebased network infrastructures, the networking community is increasingly adopting paradigms such as Network Function Virtualization (NFV) and Software-Defined Networking (SDN) [13]. NFV enables the implementation of network functions as software-based Virtual Network Functions (VNFs), allowing them to run on commodity computing platforms instead of dedicated hardware appliances. Similarly, SDN decouples the control and data planes, enabling centralized and programmable network management. These approaches improve flexibility, scalability, and resource utilization, while also reducing deployment and operational costs [14]. A wide range of network functions, including routing [15], firewalling [16], load balancing, and traffic monitoring [17], have been successfully virtualized using these paradigms [18]. However, only a limited number of studies, reviewed in Section II, have investigated the virtualization of TSN functionalities.
II. R ELATED W ORK
Fig. 1: The V-TSN overlay. Each endpoint and the switch run as software components on Linux virtual machines, interconnected over a general-purpose, non-deterministic network. The V-TSN switch replaces a physical TSN switch and implements gPTP synchronization, TAS, and CBS in software. This paper introduces V-TSN, a software-defined overlay that realizes core TSN functionalities, namely gPTP-based synchronization, TAS, and CBS, over general-purpose, nondeterministic networks without requiring specialized hardware. Unlike simulation, V-TSN runs in real time together with the unmodified application stack, and, unlike hardware TSN, it targets relaxed sub-millisecond timing precision rather than nanosecond-level guarantees. V-TSN supports two use cases: • UC1, development-time emulation: V-TSN reproduces TSN behavior so that a system can be validated before integration on physical TSN infrastructure, where we assume that the virtualized system runs at implementation speed, so that its timing reflects the eventual hardware deployment. • UC2, cost-efficient deployment: Where full TSN hardware is unnecessary and the application tolerates relaxed timing, V-TSN provides TSN-related timing behavior directly over general-purpose networks, for example in distributed sensor data collection, multimedia streaming, and coordination between edge and cloud. Fig. 1 shows the V-TSN overlay, in which endpoints and the switch run as standard computing nodes, such as cloud-based virtual machines, interconnected over a general-purpose network. We demonstrate the feasibility of the proposed approach through a real-world cloud-based deployment, evaluating synchronization accuracy, traffic isolation through virtual TAS, and bandwidth regulation through virtual CBS. The software described in this paper is available via the TU/e ES GitHub repository (https://github.com/TUE-EE-ES). The remainder of this paper is organized as follows. Section II reviews related work. Section III presents the design of the proposed V-TSN platform. Section IV evaluates the proposed approach. Finally, Section V concludes.
Realizing TSN behavior over general-purpose networks requires both time synchronization and traffic shaping, since time-aware shaping is meaningful only when nodes are synchronized. Prior work addresses parts of this problem through TSN simulation, hardware testbeds, endpoint synchronization, and, more recently, the virtualization of TSN over commodity platforms, which we review and contrast with V-TSN. TSN simulation frameworks such as OMNeT++ [19] and INSIM [12] enable offline evaluation of scheduling strategies and protocol behavior. However, they run in simulated time, far slower than real time, and cannot connect real applications, so they are unsuitable for development workflows that require interaction with actual software. Hardware testbeds such as [20] and EnGINE [21] combine Commercial Off-The-Shelf Ethernet devices with orchestration frameworks for high-fidelity measurements. They depend on physical TSN-capable infrastructure and fixed setups, which we avoid in this work. Protocols such as Linux PTP [22] and PTPd [23] assume hardware support for timestamping and synchronize network endpoints only. In contrast, V-TSN implements gPTP, which is part of the TSN standard, entirely in software. It synchronizes endpoints as well as intermediate virtualized TSN switches. The latter also implement TAS and CBS traffic shaping. Closest to our work is a recent research line that virtualizes TSN over commodity platforms. Sasiain et al. [24] propose to integrate TSN into the ETSI NFV framework, but their proposal is unimplemented, limited to TAS, and assumes TSN hardware. Zhang et al. [25] treat virtualized TSN as a controlplane problem of joint admission control and VNF embedding, evaluated in simulation rather than as a running overlay. Most similar, KuberneTSN [26] provides a deterministic container overlay with a userspace implementation of TAS and kernelbypass acceleration for Kubernetes environments. However, KuberneTSN virtualizes packet scheduling at the container host and relies on an existing TSN infrastructure for synchronization and switching. Furthermore, it is evaluated on a controlled local testbed with externally synchronized hosts and a physical TSN-compliant switch. Instead, V-TSN virtualizes the complete TSN communication substrate entirely in software. The proposed platform virtualizes both the endpoints and the switch and it operates over non-deterministic generalpurpose networks without TSN hardware. Table I summarizes the differences between existing approaches and V-TSN. III. V-TSN P LATFORM D ESIGN In V-TSN, both the endpoints and the switches are software components that can run on general-purpose hosts and be placed anywhere in the network. A virtual switch is just another software component, a virtual machine (VM) that may even run on an endpoint. To the underlying network, it carries only ordinary traffic that standard network switches forward, like any other switch. Lightweight software agents run at the endpoints, while the core networking logic resides in the
TABLE I: Comparing TSN virtualization approaches Feature Prototype implementation gPTP virtualization Virtual TSN switch TAS CBS No TSN hardware needed WAN deployment
Sasiain [24] ✗ ✗ ✗ Partial ✗ ✗ ✗
Zhang [25] ✗ ✗ ✗ ✗ ✗ N/A ✗
KuberneTSN [26] ✓ ✗ ✗ ✓ ✗ ✗1 ✗
V-TSN (Ours) ✓ ✓ ✓ ✓ ✓ ✓ ✓
1 KuberneTSN runs on commodity hosts, but its determinism is demon-
strated on a testbed with TSN-capable NICs and a physical TSN switch.
virtual V-TSN switch, on top of which the TSN functionalities are layered. The following subsections describe, first, the virtual packet switching that carries all traffic, then the software realization of gPTP for synchronization, and finally the TAS and CBS traffic shaping implemented within the V-TSN switch. A. Virtual Packet Switching Mechanism The basis of the V-TSN platform is a virtual packet switching mechanism that enables communication between distributed endpoints over a general-purpose network. Since the underlying network does not provide native TSN support, the proposed approach introduces an overlay communication layer in which Ethernet frames are encapsulated, transmitted, and processed through software-defined components at the endpoints and the virtual V-TSN switches. Fig. 2 illustrates this packet processing pipeline. At the talker, a frame encapsulation module wraps each outgoing Ethernet frame in a UDP/IP packet addressed to the V-TSN switch, enabling transport over standard IP networks. At the switch, (i) incoming packets are decapsulated, (ii) a virtual destination resolution module selects the output endpoint from a mapping table of logical endpoints to IP addresses and ports, (iii) the frame is optionally processed by the traffic shaping mechanisms, and (iv) it is then re-encapsulated and forwarded. At the listener, a decapsulation module recovers the original Ethernet frame and an application mapping mechanism delivers it to the correct endpoint component using header fields such as ports. This effectively emulates a layer-2 switch over a layer-3 network while integrating TSN traffic control. B. Virtual gPTP Synchronization Time synchronization in TSN is provided by gPTP, which aligns the local clocks of distributed nodes with a grandmaster reference clock. Unlike end-to-end protocols, gPTP is a hop-to-hop protocol: it measures link delay on each hop through a peer-delay exchange (Pdelay Req/Pdelay Resp) and distributes the reference time through Sync and Follow Up messages, which yields higher synchronization accuracy. In the V-TSN platform, gPTP is implemented by handlers that run as ordinary applications on the endpoints and the VTSN switch. One Linux VM acts as the grandmaster node. Because gPTP uses normal Ethernet packets, the exchanges are encapsulated and transported over the virtualized TSN network as described above like regular data traffic, avoiding a separate
synchronization channel and preserving the structure of gPTP communication over a non-deterministic network. C. Virtual Traffic Shaping Traffic shaping in TSN controls the timing and rate of packet transmissions to achieve predictable communication behavior. In the V-TSN platform, traffic shaping is implemented within the V-TSN switch, providing a software-based realization of TSN scheduling over a non-deterministic network. Fig. 4 illustrates the architecture of the virtual traffic shaping module. At the egress of the shaping pipeline, Ethernet frames are first classified by their Priority Code Point (PCP) values and mapped to one of eight virtual queues corresponding to the standard priority levels (PCP 0 to PCP 7), representing the logical separation of traffic classes in TSN. Two shaping mechanisms are applied within the switch: CBS and TAS. CBS is implemented through a set of virtual CBS modules. A CBS controller regulates the transmission rate of each queue by maintaining and updating credit values, ensuring bandwidth sharing and smooth traffic behavior. After CBS, the TAS mechanism is realized using a virtual Gate Control List (GCL), where each queue is associated with a gate that opens or closes according to a predefined schedule, enabling time-based control so that high-priority traffic is transmitted within specific time windows. The GCL gates open and close at specific time instants based on the global time base provided by gPTP. The accuracy of this alignment is limited by the gPTP synchronization error and each switch hop can add up to one GCL cycle of gating delay, both of which contribute to the end-to-end latency of time-critical traffic. After passing through the CBS and TAS stages, packets are forwarded to a virtual strict-priority selector, which determines the next packet to transmit based on priority. The selected packet is then transmitted through the underlying network using the encapsulation mechanism described earlier. Although these mechanisms are implemented in software and do not provide the same level of determinism and accuracy as hardware-based TSN, they preserve the logical behavior of TSN traffic shaping. This allows the V-TSN platform to emulate scheduling effects and traffic interactions, enabling meaningful evaluation of time-sensitive applications. IV. E VALUATION AND R ESULTS We evaluate the V-TSN platform deployed on a commercial cloud provider over the public Internet, with two objectives. First, we measure the clock synchronization accuracy achieved by the virtual gPTP mechanism, which determines the quality of the shared time base available to applications. It is relevant to both use cases highlighted in the introduction. Second, for the emulation use case, UC1, we validate that the virtual TAS and CBS reproduce the behavior expected of TSN traffic shapers. The aim of this second part is to confirm that the platform exhibits the characteristic TSN shaping behavior.
z
V-TSN Switch
Virtual Ingress Port
Network Node (Talker)
Ethernet Frame
Destination
Related IP
EP1 .... EPn
IP1 .... IPn
V-TSN Edge Agent (Frame Encapsulation Module)
Source IP
Dest. IP
Software Layer
Traffic Shaper (Detailed in Fig. 4.)
Ethernet Frame
Ethernet Frame
V-TSN Edge Agent (Frame Decapsulation Module)
Ethernet Frame
Frame Encapsulation Module
V-TSN Switch UDP port
Destination Source Port Port
Network Node (Listener)
Destination Finder
Software Layer
V-TSN Switch IP Address
Virtual Egress Port
Ethernet Frame
Frame Decapsulation Module UDP Data
Source IP
Dest. IP
Destination Port
Destination Endpoint IP
Source IP
V-TSN Switch UDP port
Dest. IP
Source Port
Destination Port
UDP Data
UDP Data Source IP
Encapsulated Frame
Dest. IP
Source Port
Destination Port
UDP Data
Encapsulated Frame
Linux Virtual Machine
Linux Virtual Machine Encapsulated Frame
Encapsulated Frame
Linux Virtual Machine
Fig. 2: Virtual packet switching mechanism in the V-TSN platform. TABLE II: Experimental setup summary VM VM1 VM2 VM3 VM4
Fig. 3: Virtual gPTP synchronization in the V-TSN platform.
Fig. 4: Virtual traffic shaping architecture inside the V-TSN switch, detailing the traffic shaper of Fig. 2.
A. Experimental Setup To evaluate V-TSN under realistic conditions, we deploy it on commercial cloud infrastructure rather than a controlled testbed. As summarized in Table II, the experiments use four cloud VMs acting as a grandmaster clock (and also as endpoint EP0), the V-TSN switch, and two endpoints EP1 and EP2. Three nodes are co-located in the same region, while EP2 is in a different country, introducing wide-area variability; the colocated nodes therefore represent a favorable setup and EP2
Location Germany Germany Germany Finland
Configuration Hetzner, Linux, 2 vCPU, 4 GB Hetzner, Linux, 2 vCPU, 4 GB Hetzner, Linux, 2 vCPU, 4 GB Hetzner, Linux, 2 vCPU, 4 GB
Role Grandmaster (EP0) V-TSN Switch Endpoint 1 (EP1) Endpoint 2 (EP2)
dominates the wide-area behavior. All machines communicate over UDP across the public Internet, with no TSN-capable hardware and no controlled network conditions. So the overlay runs over a genuinely non-deterministic wide-area network. All endpoint traffic is routed through the V-TSN switch, representative of a real deployment in which distributed nodes are interconnected through general-purpose cloud networks. B. Time Synchronization Accuracy We evaluate synchronization accuracy through the clock offset of each node relative to the grandmaster. At each synchronization instant, when a node receives a new reference time from the grandmaster, it computes its offset as the received grandmaster time minus its own local time at that moment. We report the absolute value of this offset. Fig. 5a shows a boxplot of 10,000 such offset samples per node collected over 80 hours, with the diamond marking the mean. For readability, samples exceeding 500 µs are excluded here and shown separately in Fig. 5b. As shown in Fig. 5a, the average clock offset remains below 200 µs for all nodes, with the V-TSN switch the most tightly synchronized, consistent with its co-location with the grandmaster. EP2, which is deployed in a different geographical location, exhibits higher offset values and larger variation compared to the other nodes. Increased geographical distance and the associated network variability have a direct impact on synchronization accuracy. Fig. 5b presents the offset samples greater than 500 µs. All three nodes exhibit such deviations, with EP1, EP2, and the switch showing 434, 647, and 369 samples above this threshold. These outliers are consistent with transient congestion events on the public Internet, suggesting that WAN latency variability is the dominant factor in worst-case synchronization error. Such deviations represent no more than about 6.5% of each node’s samples and the system recovers to normal synchronization accuracy once network conditions stabilize.