pith. sign in

arxiv: 2606.31512 · v1 · pith:D4OZUJP7new · submitted 2026-06-30 · 💻 cs.NI

Support of Teleoperated Driving with 5G Networks

Pith reviewed 2026-07-01 03:13 UTC · model grok-4.3

classification 💻 cs.NI
keywords teleoperated driving5G networksTDD frame structurelatencyvideo bitrateuplink downlink allocationremote control center
0
0 comments X

The pith

5G networks can support teleoperated driving only when TDD frame structures allocate enough bandwidth to uplink video and keep internet delays low.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper examines whether 5G networks can meet the needs of teleoperated driving, in which vehicles send video feeds and sensor data to a remote operator who takes control during complex situations. The central finding is that feasibility hinges on bandwidth size and the TDD frame structure, which sets the split between uplink transmissions from the vehicle and downlink commands. The study also shows that adding more vehicles forces each one to lower its video bitrate to stay within network limits. In addition, standard centralized 5G setups can fail the tightest latency targets because of delays introduced by the internet link to the control center.

Core claim

The feasibility to support ToD with 5G networks strongly depends on the bandwidth and the Time Division Duplexing (TDD) frame structure that conditions how the bandwidth is distributed between uplink and downlink transmissions. Scaling the number of 5G-supported ToD vehicles requires the vehicles to reduce the video bitrates. Traditional centralized 5G network deployments may be challenged by some of the most stringent ToD latency requirements due to the latency introduced by the Internet connection to the ToD control center.

What carries the argument

The TDD frame structure that sets the division of bandwidth between uplink video and sensor data from the vehicle and downlink control signals.

If this is right

  • More ToD vehicles on the same 5G cell forces each vehicle to cut its video bitrate.
  • Traditional centralized 5G deployments introduce internet delays that can violate the most demanding ToD latency targets.
  • TDD frame configuration directly controls whether uplink video capacity meets ToD reliability needs.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Edge-based control centers could bypass some internet latency and improve feasibility.
  • Comparing TDD results against FDD or other duplexing schemes would test whether the identified limits are duplexing-specific.
  • Field trials with actual ToD vehicles could check whether the assumed latency thresholds match real safety requirements.

Load-bearing premise

The primary bottlenecks are the TDD bandwidth split and added internet latency to the control center.

What would settle it

A direct measurement in a live 5G deployment showing multiple vehicles sending full-bitrate video with end-to-end latency below the strictest ToD threshold without any bitrate reduction.

Figures

Figures reproduced from arXiv: 2606.31512 by Baldomero Coll-Perales, Javier Gozalvez, M.Carmen Lucas-Esta\~n, Miguel Sepulcre, Mohammad Irfan Khan, Onur Altintas, Sergei S. Avedisov.

Figure 2
Figure 2. Figure 2: a depicts the average and 99th percentile of the UL latency (i.e., from the vehicle to the ToD control center) for different cell bandwidths (BW) and 5G configurations (FDD and different TDD)3 . The figure does not show 99th percentile values for TDD1 and TDD2 with BW<60 MHz since these configurations cannot meet the reliability requirement as the percentage of packets received before the latency limit is … view at source ↗
read the original abstract

Teleoperated driving (ToD) can support autonomous driving under complex or unexpected traffic scenarios that an autonomous vehicle may not understand or be able to handle. In ToD, autonomous vehicles transmit video feeds and perception data to the remote control center. The operator uses this data to understand the driving environment and remotely control the vehicle that can take over the control once the scenario is resolved. ToD requires reliable and low latency communications between the vehicle and the ToD control center. This study analyzes the feasibility to support ToD with 5G networks. The study demonstrates that the feasibility strongly depends on the bandwidth and the Time Division Duplexing (TDD) frame structure that conditions how the bandwidth is distributed between uplink and downlink transmissions. The study also shows that scaling the number of 5G-supported ToD vehicles requires the vehicles to reduce the video bitrates. The study also shows that traditional centralized 5G network deployments may be challenged by some of the most stringent ToD latency requirements due to the latency introduced by the Internet connection to the ToD control center.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 0 minor

Summary. The manuscript analyzes the feasibility of supporting teleoperated driving (ToD) with 5G networks. It concludes that feasibility strongly depends on bandwidth and the TDD frame structure for uplink/downlink allocation, that scaling the number of supported ToD vehicles requires vehicles to reduce video bitrates, and that traditional centralized 5G deployments may be challenged by stringent ToD latency requirements due to added latency from the Internet connection to the ToD control center.

Significance. If the underlying network models and calculations hold, the work identifies practically relevant bottlenecks for 5G-based remote driving, particularly around TDD configuration and core-network latency, which could guide deployment choices for safety-critical vehicular applications.

major comments (1)
  1. [Abstract] Abstract: the central claims that feasibility 'strongly depends' on bandwidth and TDD frame structure, that scaling requires bitrate reduction, and that centralized deployments are challenged by Internet latency are stated without any network model, capacity equations, end-to-end latency budget (e.g., control-loop threshold in ms), or numerical results. This absence makes it impossible to verify whether the identified factors actually dominate or whether the scaling/bitrate conclusions follow from the analysis.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the review and for highlighting the need for clearer linkage between the abstract claims and the supporting analysis. We address the single major comment below.

read point-by-point responses
  1. Referee: [Abstract] Abstract: the central claims that feasibility 'strongly depends' on bandwidth and TDD frame structure, that scaling requires bitrate reduction, and that centralized deployments are challenged by Internet latency are stated without any network model, capacity equations, end-to-end latency budget (e.g., control-loop threshold in ms), or numerical results. This absence makes it impossible to verify whether the identified factors actually dominate or whether the scaling/bitrate conclusions follow from the analysis.

    Authors: The abstract is intended as a concise summary of findings derived from the full analysis. The manuscript presents a 5G NR network model (Section II) with capacity equations based on TDD slot configurations and bandwidth allocation, an end-to-end latency budget that incorporates control-loop thresholds (typically 20-100 ms depending on the ToD use case), and numerical results (Section IV) that quantify the impact of bandwidth, TDD patterns, vehicle scaling, and core-network/Internet latency. The stated conclusions follow directly from these calculations. To improve readability of the abstract, we will add a short clause referencing the underlying models and key quantitative outcomes. revision: yes

Circularity Check

0 steps flagged

No circularity: feasibility claims rest on external network parameters

full rationale

The paper's central claims—that ToD feasibility depends on bandwidth/TDD allocation, that scaling requires bitrate reduction, and that centralized deployments face internet-induced latency—are presented as outcomes of network analysis rather than reductions to fitted parameters or self-citations. No equations, self-definitional loops, or load-bearing self-citations appear in the abstract or described structure; the derivation chain relies on standard 5G TDD and latency models treated as independent inputs. This is the expected non-finding for an empirical feasibility study whose conclusions can be checked against external 5G specifications.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The abstract does not specify any free parameters, axioms, or invented entities; claims are presented at a high level without detailing underlying models or assumptions beyond the stated dependencies on bandwidth and TDD.

pith-pipeline@v0.9.1-grok · 5747 in / 1147 out tokens · 62181 ms · 2026-07-01T03:13:36.325392+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

21 extracted references · 1 canonical work pages

  1. [1]

    Support of Teleoperated Driving with 5G Networks

    considers a 2x20 MHz Frequency Division Duplexing (FDD) 5G network with the ToD control center using a dedicated 10 Gb/s wired connection to the mobile network. The simulation-based study fo cuses again on a single ToD vehicle transmitting video at 32 Mbps (following 5G Automotive Associate -5GAA- ToD requirements in [2]) but considers additional backgrou...

  2. [2]

    We consider a traditional centralized 5G network deployment such as the one depicted in Fig

    and [8]. We consider a traditional centralized 5G network deployment such as the one depicted in Fig. 1. In this case, the latency model accounts for the latency experienced at the radio, transport (TN) and core (CN) networks ( l radio, lTN and lCN, respectively), and the latency introduced by the Internet connection between the last UPF (User Plane Funct...

  3. [3]

    The network implements a hierarchical TN with 3 multiplexing nodes (M1, M2 and M3 in Fig

    that follows the topology recommended by ITU in [11]. The network implements a hierarchical TN with 3 multiplexing nodes (M1, M2 and M3 in Fig. 1) that multiplex the traffic from 6 gNBs, 24 M1 and 12 M2 nodes, respectively. The distance and link capacities between any two nodes of the network are indicated in Fig. 1. We estimate and reserve for V2X traffi...

  4. [4]

    Packets may not be received because there is a transmission error or because they are dropped at the transmitter

    The figure does not show 99th percentile values for TDD1 and TDD2 with BW<60 MHz since these configurations cannot meet the reliability requirement as the percentage of packets received before the latency limit is below 99%. Packets may not be received because there is a transmission error or because they are dropped at the transmitter. A vehicle would dr...

  5. [5]

    European Union NextGenerationEU/PRTR

    Fig. 2.a also shows that the maximum UL latency experienced by 99% of the packets with FDD is slightly larger than using TDD3 when BW<70 MHz despite allocating the same per centage of resources for UL transmissions. This is because the FDD configuration only uses half the bandwidth (BW/2) for UL transmissions. In this case, video frames need to be segment...

  6. [6]

    Simulation of Tele-Operated Driving over 5G Using CARLA and OMNeT++

    V. Cislaghi, C. Quadri, V. Mancuso and M. A. Marsan, "Simulation of Tele-Operated Driving over 5G Using CARLA and OMNeT++", Proc. IEEE VNC, pp. 81-88, Istanbul, Turkiye, 2023

  7. [7]

    C-V2X Use Cases and Service Level Requirements: Volume II

    5GAA, “C-V2X Use Cases and Service Level Requirements: Volume II”, Technical Report, February 2021

  8. [8]

    Investigating Remote Driving over the LTE Network

    R. Liu, D. Kwak, S. Devarakonda, K. Bekris, and L. Iftode, “Investigating Remote Driving over the LTE Network”, Proc. 9th ACM AutomotiveUI, pp. 264–269, NY, USA, 2017

  9. [9]

    Tele-Operated Driving (T oD): Use Cases and Technical Requirements

    5GAA, “Tele-Operated Driving (T oD): Use Cases and Technical Requirements”, Technical Report, August 2021

  10. [10]

    Tele-Operated Driving (ToD): System Requirements Analysis and Architecture

    5GAA, “Tele-Operated Driving (ToD): System Requirements Analysis and Architecture”, Technical Report, July 2021

  11. [11]

    Tech. Specification Group Services and System Aspects; Service requirements for the 5G system; Stage 1 (Rel. 17)

    3GPP TS 22.261 V17.6.0, “Tech. Specification Group Services and System Aspects; Service requirements for the 5G system; Stage 1 (Rel. 17)”, March 2021

  12. [12]

    An Analytical Latency Model and Evaluation of the Capacity of 5G NR to Support V2X Services using V2N2V Communications

    M.C. Lucas-Estañ, et al., “An Analytical Latency Model and Evaluation of the Capacity of 5G NR to Support V2X Services using V2N2V Communications”, IEEE Transactions on Vehicular Technology, vol. 72, no. 2, pp. 2293-2306, Feb. 2023

  13. [13]

    End-to-End V2X Latency Modeling and Analysis in 5G Networks

    B. Coll-Perales, et al., “End-to-End V2X Latency Modeling and Analysis in 5G Networks”, IEEE Transactions on Vehicular Technology, vol. 72, no. 4, pp. 5094-5109, April 2023

  14. [14]

    Impact of the COVID-19 pandemic on the Internet latency: A large-scale study

    M. Candela. V. Luconi, and A. V ecchio, “Impact of the COVID-19 pandemic on the Internet latency: A large-scale study”, Comput. Netw., vol. 182, 107495, Dec. 2020

  15. [15]

    First Phase Trial Ex ecution Report and Analysis of 5GCroCo KPIs

    5GCroco, “First Phase Trial Ex ecution Report and Analysis of 5GCroCo KPIs”, Deliverable D4.2v3.0, Jun. 2021

  16. [16]

    Consideration on 5G transport network reference architecture and bandwidth requirements

    ITU-T, “Consideration on 5G transport network reference architecture and bandwidth requirements”, Study Group 15, #0462, Feb. 2018

  17. [17]

    Tech. Specification Group Radio Access Network; Study on evaluation me thodology of new Vehicle-to- Everything (V2X) use cases for LTE and NR (Rel. 15)

    3GPP TS 37.885 V15.3.0, “Tech. Specification Group Radio Access Network; Study on evaluation me thodology of new Vehicle-to- Everything (V2X) use cases for LTE and NR (Rel. 15)”, June 2019

  18. [18]

    Tech. Specification Group Radio Access Network; NR; Physical layer procedures for data (Rel. 16)

    3GPP TS 38.214 V16.1.0, “Tech. Specification Group Radio Access Network; NR; Physical layer procedures for data (Rel. 16)”, 2020

  19. [19]

    GSMA, 5G TDD Synchronisation Guidelines and Recommendations for the Coexistence of TDD Networks in the 3.5 GHz Range, 2020

  20. [20]

    Tech. Sp ecification Group Radio Access Network; NR; Physical layer procedures for control (Rel. 16)

    3GPP TS 38.213 V16.0.0 “Tech. Sp ecification Group Radio Access Network; NR; Physical layer procedures for control (Rel. 16)”, 2020

  21. [21]

    Report on corridor infrastructure development and integration

    5GMobix, “Report on corridor infrastructure development and integration”, Deliverable D3.4, v2.0, April 2022