nascTime：带 SDAP QoS 映射和 802.1AS 透明时钟的全栈 5G-TSN Bridge 仿真框架

IEEE 802.1 Time-Sensitive Networking (TSN) has become the predominant standard for deterministic industrial Ethernet [ 1 ], providing bounded latency, high reliability, and precise clock synchronisation through mechanisms such as IEEE 802.1Qbv time-aware shaping and IEEE 802.1AS generalised precision time synchronisation. Modern factory floors, however, increasingly require wireless connectivity for autonomous mobile robots, collaborative manipulators, and reconfigurable production cells, applications that wired TSN alone cannot serve.

5G New Radio with Ultra-Reliable Low-Latency Communication (URLLC) is well suited to fill this role. 3GPP Release 16 specifies how a 5G system operates as a logical TSN bridge, transparently connecting wired TSN segments through the wireless domain [ 2 ]. The bridge architecture comprises a Network-side TSN Translator (NW-TT) at the User Plane Function, a Device-side TSN Translator (DS-TT) at the User Equipment, and a TSN Application Function (TSN AF) that exposes bridge capabilities to the TSN Centralized Network Controller. The specification defines QoS mapping between TSN Priority Code Points (PCP) and 5G QoS Flow Identifiers (QFI), as well as IEEE 802.1AS transparent clock behaviour in which the 5G system reports its residence time in the gPTP correction field

Several simulation frameworks have been developed to study 5G-TSN integration. The 5GTQ framework [ 3 ] implements NW-TT and DS-TT modules with QoS-aware priority scheduling, but maps traffic priority at the MAC scheduler level without utilizing the 3GPP SDAP layer for per-flow Data Radio Bearer (DRB) selection, and does not model gPTP time synchronization. Da Silva et al. [ 4 ] focus exclusively on time synchronization, modifying INET’s IEEE 802.1AS model for UDP/IP transport over 5G, but do not implement data plane traffic forwarding through the bridge. The 6GDetCom Simulator [ 5 ] models TSN traffic shaping with a configurable wireless delay element, but does not simulate the actual 5G radio access network—replacing it with statistical delay distributions that cannot capture the impact of MAC scheduling, HARQ retransmissions, or multi-user resource contention.

In this paper, we present nascTime, a full-stack simulation framework for the 3GPP Release 16 5G-TSN bridge architecture. Our contributions are:

1. Complete bridge architecture with SDAP-based QoS: nascTime implements the NW-TT and DS-TT as modular OMNeT++ compound modules that integrate with INET’s LayeredEthernetInterface. The QoS pipeline maps TSN PCP through IPv4 DSCP to 5G QFI, which the SDAP layer [ 18 ] —originally contributed by us to Simu5G v1.4.1 [ 19 ] —uses to select specific Data Radio Bearers, enabling per-flow scheduling at the gNB MAC layer. 2. IEEE 802.1AS transparent clock with measured residence time: gPTP frames are transported through the actual simulated 5G radio path using L2-in-GTP-U encapsulation. A custom GptpResidenceHeader carries the NW-TT ingress timestamp, enabling the DS-TT to compute the actual 5G system residence time and update the IEEE 802.1AS correction field per message type. 3. Multi-endpoint validation with bidirectional traffic: nascTime supports multiple UE/DS-TT pairs sharing a single gNB, with per-endpoint QoS configuration, gPTP replication, and bidirectional traffic. We validate the framework with a three-endpoint topology demonstrating near-perfect data delivery, correct time synchronization, and zero packet loss.

Complete bridge architecture with SDAP-based QoS: nascTime implements the NW-TT and DS-TT as modular OMNeT++ compound modules that integrate with INET’s LayeredEthernetInterface. The QoS pipeline maps TSN PCP through IPv4 DSCP to 5G QFI, which the SDAP layer [ 18 ] —originally contributed by us to Simu5G v1.4.1 [ 19 ] —uses to select specific Data Radio Bearers, enabling per-flow scheduling at the gNB MAC layer.

IEEE 802.1AS transparent clock with measured residence time: gPTP frames are transported through the actual simulated 5G radio path using L2-in-GTP-U encapsulation. A custom GptpResidenceHeader carries the NW-TT ingress timestamp, enabling the DS-TT to compute the actual 5G system residence time and update the IEEE 802.1AS correction field per message type.

Multi-endpoint validation with bidirectional traffic: nascTime supports multiple UE/DS-TT pairs sharing a single gNB, with per-endpoint QoS configuration, gPTP replication, and bidirectional traffic. We validate the framework with a three-endpoint topology demonstrating near-perfect data delivery, correct time synchronization, and zero packet loss.

The remainder of this paper is organized as follows. Section II provides background on the 5G-TSN bridge architecture and reviews related simulation frameworks. Section III describes the nascTime framework architecture. Section IV discusses implementation details and integration challenges. Section V presents validation results, and Section VI concludes the paper.

The 3GPP Release 16 specification TS 23.501 §5.28 [ 2 ] defines how a 5G system operates as one or more virtual IEEE 802.1 TSN bridges. As illustrated in Fig. 1, the bridge comprises two TSN Translator ports:

The Network-side TSN Translator (NW-TT), located at the User Plane Function (UPF), connects the external TSN network to the 5G core. It translates between IEEE 802.1Q Ethernet frames and IP datagrams, mapping TSN QoS parameters to 5G QoS parameters for transport through the 5G system.

The Device-side TSN Translator (DS-TT), located at the User Plane Function (UPF), connects the external TSN network to the 5G core. It translates between IEEE 802.1Q Ethernet frames and IP datagrams, mapping TSN QoS parameters to 5G QoS parameters for transport through the 5G system.

The TSN Application Function (TSN AF) provides the control plane interface between the 5G system and the TSN Centralized Network Controller (CNC). It exposes bridge capabilities including port-pair delays, supported traffic classes, and per-stream filtering and policing capabilities.

QoS mapping follows a multi-stage pipeline: the NW-TT reads the Priority Code Point (PCP) from the IEEE 802.1Q VLAN tag and maps it to an IPv4 Differentiated Services Code Point (DSCP). The UPF’s Traffic Flow Filter maps DSCP to a 5G QoS Flow Identifier (QFI), which the SDAP layer uses to select a specific Data Radio Bearer (DRB). At the DS-TT, the process reverses: the IPv4 DSCP is mapped back to a PCP value in the reconstructed VLAN tag.

For time synchronization, the 5G system operates as an IEEE 802.1AS transparent clock. The NW-TT records the ingress timestamp when a gPTP frame enters the bridge. At the DS-TT, the residence time—the total delay through the 5G system, is computed and added to the gPTP correction field. This enables downstream TSN devices to account for the 5G bridge delay in their clock synchronization.

Table I compares nascTime with existing 5G-TSN simulation frameworks across key architectural features.

The 5GTQ framework [ 3 ] was among the first to address QoS-aware 5G-TSN simulation, implementing NW-TT and DS-TT modules with priority-based scheduling. However, 5GTQ maps traffic priority directly at the MAC scheduler level using 5QI values without utilising the 3GPP SDAP layer for per-flow DRB selection. All traffic therefore shares a single radio bearer regardless of its TSN priority class. Furthermore, 5GTQ does not model gPTP time synchronisation or residence time measurement.

Da Silva et al. [ 4 ] address time synchronization by modifying INET’s IEEE 802.1AS model to operate over UDP/IP through the 5G network, demonstrating synchronization accuracy below one microsecond. Their work supports 3GPP Release 17 time-aware system modes and validates synchronization in multiple clock master configurations. However, their framework does not implement data plane traffic forwarding—only gPTP control frames are transported through the 5G system. Without NW-TT/DS-TT data forwarding, QoS mapping, or traffic delivery validation, the framework cannot evaluate the bridge’s performance under realistic mixed traffic conditions.

The 6GDetCom Simulator [ 5 ], developed within the EU DETERMINISTIC6G project, models end-to-end deterministic communication across heterogeneous domains including 6G wireless segments. The wireless domain is represented as a configurable delay element with statistical characteristics (mean, variance, distribution), enabling analysis of TSN scheduling algorithms such as Time-Aware Shaping under wireless delay uncertainty. However, the simulator does not include an actual 5G radio access network—there is no MAC scheduler, HARQ, channel model, or resource block allocation. Consequently, it cannot capture the effects of multi-user contention, fading, or scheduling discipline on bridge performance.

Additional related work includes Muslim et al. [ 6 ], who extend the 802.1AS-over-UDP/IP approach with 5G handover scenarios; the P5G-TSN framework [ 7 ], which extends 5GTQ with TDD pattern analysis; and Wang et al. [ 8 ], who study time synchronisation collisions in large-scale 5G+TSN networks. None of these frameworks implement the complete QoS pipeline through the SDAP layer or validate multi-endpoint data delivery with measured residence time.

Satka et al. provide a systematic review of TSN-5G integration [ 15 ], identifying time synchronisation as the dominant research focus (73% of studies) and QoS mapping as an open challenge. Their QoS-MAN algorithm [ 16 ] maps TSN flows to 5G QoS flows based on deadline, jitter, bandwidth, and packet loss constraints, and they developed an early NeSTiNg-based translation technique [ 17 ]. QoS-MAN operates at the flow-to-5QI assignment level and has not been evaluated within a full-stack simulation including the SDAP/DRB pipeline and measured residence time. nascTime provides the simulation infrastructure to evaluate such algorithms under realistic radio conditions.

No existing simulation framework combines (1) actual 5G radio simulation with MAC scheduling and channel models, (2) end-to-end QoS mapping through the SDAP/DRB pipeline, (3) measured IEEE 802.1AS residence time from actual radio path traversal, (4) multi-endpoint scaling with bidirectional traffic validation, and (5) integration with INET’s LayeredEthernetInterface for TSN feature compatibility. nascTime addresses all five requirements.

The NW-TT is implemented as a compound module extending INET’s NetworkLayerNodeBase, following the same architectural pattern as Simu5G’s UPF module. Fig. 2 shows the internal structure. The TSN-facing port uses INET’s LayeredEthernetInterface with EthernetStreamingPhyLayer, connected through a EthernetStreamingPhyLayer (ethLi) to the NwTtTranslator simple module. The UPF-facing port uses a standard PppInterface connected through the inherited network layer dispatcher. On the ingress path (TSN → 5GS), the translator receives complete Ethernet frames from the TSN switch, detects gPTP frames by ethertype (0x88F7), and processes data and gPTP frames differently:

Data frames: The translator strips the IEEE 802.1Q VLAN tag, reads the PCP value, maps it to an IPv4 DSCP field, and forwards the IPv4 datagram to the UPF via the PPP interface. The UPF’s Traffic Flow Filter reads the DSCP and sets the corresponding QFI in the GTP-U tunnel header.

gPTP frames: The translator prepends a custom GptpResidenceHeader carrying the current simulation time as the ingress timestamp, wraps the complete gPTP Ethernet frame in a UDP packet (port 30001), and sends it as an IPv4 datagram through the 5G system. For multi-endpoint topologies, the gPTP frame is replicated to all registered downstream devices.

On the egress path (5GS → TSN), return traffic from the UPF is routed by the NW-TT’s IPv4 stack through an EthernetEncapsulation module, which adds MAC framing and sends the frame to the TSN switch via the ethLi dispatcher. Multi-endpoint support is achieved through a JSON-configurable array of address, ue pairs. At initialization, the translator registers each downstream TSN device’s IP address with the Simu5G binder, mapping it to the corresponding UE’s NR node identifier obtained from the binder’s node information map.

The DS-TT is a standalone two-port L2 bridge with two LayeredEthernetInterface ports connected through EthernetStreamingPhyLayer modules to the DsTtTranslator. Fig. 3 shows the internal structure. The TSN-facing port (tsnEth) uses streaming PHY for compatibility with TSN devices, while the UE-facing port (ueEth) uses non-streaming PHY to match the UE’s standard Ethernet interface. On the forward path (UE → TSN), the translator strips the incoming Ethernet framing, checks for gPTP-in-UDP encapsulation (destination port 30001), and processes accordingly:

Data frames: The translator reads the IPv4 DSCP, maps it to a PCP value, reconstructs a complete Ethernet frame with the corresponding VLAN tag, and sends it to the downstream TSN device.

gPTP frames: The translator strips the IPv4 and UDP headers, reads the GptpResidenceHeader to obtain the NW-TT ingress timestamp, computes the residence time as the difference between the current time and the ingress time, and updates the gPTP correction field. Sync and Follow_Up messages are handled separately with type-specific chunk operations to ensure correct field modification.

On the reverse path (TSN → UE), frames from the downstream TSN device are forwarded to the UE with appropriate MAC address preservation and Ethernet framing.

Fig. 4 illustrates the complete end-to-end QoS mapping pipeline from TSN Device A through the 5G system to TSN Device B. The pipeline operates in six stages: 1. TSN Device A encodes traffic streams with IEEE 802.1Q VLAN tags carrying PCP values (e.g., PCP=6 for isochronous control, PCP=0 for best effort) 2. The NW-TT strips the VLAN tag and maps PCP to IPv4 DSCP 3. The UPF Traffic Flow Filter maps DSCP to QFI 4. The gNB SDAP layer selects a DRB based on QFI (e.g., QFI=6 → DRB 1) 5. The MAC scheduler allocates radio resources per DRB with configurable discipline (MAXCI, PF, RR) 6. The DS-TT maps DSCP back to PCP in the reconstructed VLAN tag

TSN Device A encodes traffic streams with IEEE 802.1Q VLAN tags carrying PCP values (e.g., PCP=6 for isochronous control, PCP=0 for best effort)

The NW-TT strips the VLAN tag and maps PCP to IPv4 DSCP

The UPF Traffic Flow Filter maps DSCP to QFI

The gNB SDAP layer selects a DRB based on QFI (e.g., QFI=6 → DRB 1)

The MAC scheduler allocates radio resources per DRB with configurable discipline (MAXCI, PF, RR)

The DS-TT maps DSCP back to PCP in the reconstructed VLAN tag

The SDAP layer configuration uses per-UE DRB mapping specified as JSON arrays in the simulation configuration, with explicit NR node identifiers for the gNB side. This enables independent QoS treatment for each UE in multi-endpoint topologies.

The TSN AF module subscribes to the DS-TT’s residence time signal for live bridge delay tracking, publishing minimum, maximum, and average delay as queryable parameters. It reads CNC configuration from an XML file specifying stream reservations with per-stream bandwidth and maximum latency constraints, and detects QoS violations when the measured bridge delay exceeds the configured threshold.

The Static BMCA module reads the gPTP clock hierarchy from the simulation configuration, validates the topology (single grandmaster, no missing roles), and registers the 5G system as a transparent clock. While INET’s gPTP module does not support dynamic BMCA, the static configuration is sufficient for simulation scenarios where the topology is known at design time.

Integrating the bridge modules with INET’s LayeredEthernetInterface required solving several architectural challenges: • Gate chain compatibility. LayeredEthernetInterface extends INET’s NetworkInterface, which uses an internal pushPacket() mechanism incompatible with direct connections to plain OMNeT++ simple modules. We insert MessageDispatcher modules between each interface and the translator, with serviceMapping parameters routing the ethernetmac protocol to the correct interface. • Protocol registration. The translators register Protocol::ethernetMac on their dispatcher-facing gates at initialisation, enabling the dispatchers to route incoming Ethernet frames to the translator. Outgoing frames require explicit DispatchProtocolReq and DirectionTag tags for correct routing through the dispatcher to the interface. • Egress path architecture. The NW-TT uses EthernetEncapsulation for the egress path (5GS → \rightarrow TSN), with registerProtocol=false to prevent registration conflicts on the ethLi dispatcher. The encapsulation service is manually registered on the network layer dispatcher from the translator’s initialisation code. • PHY asymmetry. The DS-TT’s TSN-facing port uses streaming PHY (matching TSN devices), while the UE-facing port uses non-streaming PHY (matching the UE’s standard Ethernet interface). This asymmetry arises because the UE extends Simu5G’s NRUe, which uses plain EthernetInterface internally.

Gate chain compatibility. LayeredEthernetInterface extends INET’s NetworkInterface, which uses an internal pushPacket() mechanism incompatible with direct connections to plain OMNeT++ simple modules. We insert MessageDispatcher modules between each interface and the translator, with serviceMapping parameters routing the ethernetmac protocol to the correct interface.

Protocol registration. The translators register Protocol::ethernetMac on their dispatcher-facing gates at initialisation, enabling the dispatchers to route incoming Ethernet frames to the translator. Outgoing frames require explicit DispatchProtocolReq and DirectionTag tags for correct routing through the dispatcher to the interface.

Egress path architecture. The NW-TT uses EthernetEncapsulation for the egress path (5GS → \rightarrow TSN), with registerProtocol=false to prevent registration conflicts on the ethLi dispatcher. The encapsulation service is manually registered on the network layer dispatcher from the translator’s initialisation code.

PHY asymmetry. The DS-TT’s TSN-facing port uses streaming PHY (matching TSN devices), while the UE-facing port uses non-streaming PHY (matching the UE’s standard Ethernet interface). This asymmetry arises because the UE extends Simu5G’s NRUe, which uses plain EthernetInterface internally.

NR node identifier resolution: The binder registration for downstream TSN device IPs requires NR node identifiers (≥ \geq 2049), not LTE identifiers (≥ \geq 1025). The translator scans the binder’s node information map at initialisation to find each UE module’s NR node identifier.

Multi-UE SDAP/DRB: The SDAP layer [ 18 ], which we contributed to Simu5G v1.4.1 for per-flow QoS differentiation through DRB selection [ 19 ], requires multiSession=true on the PDCP and RLC submodules of Simu5G’s NRNicEnbDrb module for multi-UE operation—the original default of false limits each DRB instance to a single UE session.

UE with Ethernet port: Custom NED modules (NRUeDsTt, NRUeDsTtDrb) extend Simu5G’s NR UE with an Ethernet interface, enabling connection to the external DS-TT bridge.

We validate nascTime [ 20 ] using a three-endpoint topology (Fig. 5) simulated with OMNeT++ 6.3, INET 4.6, and Simu5G v1.4.1-sdap-2. The topology comprises one TSN Device A (gPTP grandmaster), one TSN switch, one NW-TT, one UPF, one gNB, three UE/DS-TT pairs, and three downstream TSN Devices B. Table II lists the simulation parameters.

Each endpoint receives two traffic classes from TSN Device A: high-priority isochronous traffic (PCP=6 → \rightarrow DRB 1) and best-effort monitoring traffic (PCP=0 → \rightarrow DRB 0). Each TSN Device B sends reverse traffic to Device A. gPTP frames are replicated to all endpoints via L2-in-GTP-U.

Table III summarises the per-endpoint packet delivery results under the ideal channel configuration.

High-priority traffic achieves 99.9% delivery across all three endpoints; the shortfall of 7–10 packets per endpoint occurs during the first milliseconds before the radio link is fully established. Best-effort delivery varies between 5,020 and 5,122 packets due to the exponential inter-arrival distribution. Device A receives all 2,400 reverse packets (800 per endpoint), confirming correct bidirectional forwarding through the NW-TT egress path. No packets are dropped at any bridge component.

Table IV reports the measured one-way delay from TSN Device A’s application layer to TSN Device B’s application layer, separated by traffic class.

High-priority traffic on DRB 1 shows tight delay distribution (mean 2.58 ms, max 3.41 ms), consistent with the MAXCI scheduler allocating radio resources preferentially to DRB 1. Best-effort traffic on DRB 0 has a wider spread, reflecting its lower scheduling priority and the exponential inter-arrival pattern that occasionally creates bursts competing for shared resources. The 1.16 ms gap between the two mean values quantifies the QoS differentiation achieved through SDAP-based DRB selection—an effect that scheduler-priority-only approaches (e.g., 5GTQ) cannot produce, since they multiplex both classes onto a single bearer.

To verify that multi-endpoint scaling does not degrade per-flow QoS, we compare the three-endpoint configuration against a single-endpoint baseline using identical traffic parameters per endpoint.

Scaling from one to three endpoints adds less than 70 μ \mu s to the mean high-priority delay and does not affect delivery ratio or gPTP accuracy. The additional UEs share the gNB’s 25 resource blocks without contention under this load; the scaling behaviour under higher endpoint counts and realistic channel conditions is the subject of ongoing work.

To demonstrate nascTime’s ability to capture radio-induced timing effects, we repeat the three-endpoint experiment with the Simu5G INDOOR_HOTSPOT channel model (Rayleigh fading, no shadowing). Table VI compares residence time statistics.

Under fading, the residence time variance increases by more than two orders of magnitude (from < < 0.2 μ \mu s to 48.2 μ \mu s), reflecting HARQ retransmissions and variable scheduling delays. High-priority delivery remains above 99.7%. This result confirms that nascTime captures the stochastic effects of the 5G radio channel on TSN bridge timing—a capability absent from simulators that model the wireless segment as a fixed-delay element [ 5 ].

The NW-TT replicates each gPTP frame to all three downstream devices, resulting in 158 gPTP frames per endpoint (474 total). The DS-TT correctly updates the IEEE 802.1AS correction field separately for Sync and Follow_Up messages, as verified by log inspection. Under the ideal channel, the correction values are tightly clustered around 2,499.9 μ \mu s; under fading, they exhibit the variance reported in Table VI, faithfully reflecting the actual radio path delay experienced by each gPTP frame.

The TSN AF reports live bridge delay statistics (min, max, mean), and the Static BMCA validates the six-node clock hierarchy (one master, one bridge, three slaves, one transparent clock) with zero configuration errors.

The current validation uses a limited topology (three endpoints, single gNB) and does not include TAS gate scheduling coordination with the 5G bridge delay. The DS-TT does not respond to gPTP PdelayReq messages, and the Static BMCA does not support dynamic reconfiguration. These are addressed in ongoing work.

This paper presented nascTime, a simulation framework for the 3GPP Release 16 5G-TSN bridge architecture on OMNeT++ 6.3, INET 4.6, and Simu5G. The framework is the first to combine a full 5G radio stack with SDAP-based per-flow DRB selection, measured IEEE 802.1AS residence time via L2-in-GTP-U gPTP transport, and multi-endpoint scaling with bidirectional traffic.

Validation with a three-endpoint topology shows that high-priority traffic achieves 99.9% delivery with a mean delay of 2.58 ms under an ideal channel, and that residence time variance increases from < < 0.2 μ \mu s to 48 μ \mu s under fading—confirming that nascTime captures radio-induced timing effects. Scaling from one to three endpoints adds less than 70 μ \mu s to the mean delay with no packet loss.

Future work targets scalability analysis up to 20 endpoints under realistic factory channel models, coordination of TAS gate schedules with the measured 5G bridge delay, and public release of the framework source code [ 20 ].