CloudEmu: A Trace-Driven Cloud-Native Emulation Testbed for Vehicle Video Uplink over Cellular Networks Takashi Torii† , Soto Anno† , Masaki Okada, Takuma Tsubaki, Nobuhiro Azuma, and Takuya Tojo
arXiv:2605.09910v1 [cs.NI] 11 May 2026
Network Service Systems Labs., NTT, Inc., Tokyo, Japan E-mail: {takashi.torii, soto.anno, masaki.okada, takuma.tsubaki, nobuhiro.azuma, takuya.tojo}@ntt.com Abstract—We present CloudEmu, a trace-driven, cloud-native cellular-emulation testbed for vehicle video uplink communication. Reliable, low-latency video uplink over cellular networks is essential for remote monitoring of autonomous vehicles. However, existing testbeds fall into two extremes. Physical-vehicle platforms provide realism but are costly and make validation under identical network conditions difficult, whereas simulations are inexpensive and reproducible but generally cannot replay fieldmeasured end-to-end performance dynamics without substantial calibration or readily run production video-uplink stacks. A software-defined, cloud-native emulation approach can combine the fidelity of trace-driven replay with the agility and scalability that network softwarization principles offer. To this end, we propose CloudEmu that replays time-synchronized cellular and position traces, collected once from vehicles, on commodity Linux-based virtual vehicle and video-receiver nodes. A Linuxbased emulation framework couples traffic replay with position replay, tying network dynamics to each point along the route and enabling repeatable, route-aware experiments without repeated on-road trials. Our demo deploys a production-grade videouplink stack on CloudEmu, allowing attendees to experience lowcost, repeatable trials and controlled comparisons under identical replayed network conditions. Index Terms—Video streaming, Cellular networks, Network emulation, Cloud computing, Vehicular communications
I. I NTRODUCTION As the deployment of autonomous vehicles progresses, ensuring their safe operation increasingly relies on remote monitoring. In this system, a remote operator monitors vehicles through continuous uplink video streams and may intervene when needed [1]. Thus, remote monitoring of autonomous vehicles requires low-latency and highly reliable communication over commercial cellular networks on public roads. These requirements have motivated both academia and industry to develop testbeds for evaluating vehicle videouplink communication stacks for remote monitoring [1]. Most existing testbeds fall into two categories: physicalvehicle platforms and simulation-based environments [2]– [4]. The former often use real vehicles on public roads [2], incurring high operational costs for repeated trials and providing limited reproducibility under dynamic cellular conditions. Researchers have also explored scaled-down vehicles on dedicated tracks to reduce testing costs [5]. However, the reduced size limits the driving area and speed, hindering the evaluation † S. Anno equally contributed to this work as T. Torii.
of mobility-induced effects such as cellular handovers that can significantly affect uplink video quality. Simulation-based testbeds model vehicles, wireless channels, and applications entirely in software to avoid the cost of on-road trials [3], [4]. However, they often either (i) require substantial model tuning and validation against field measurements to match the time-varying, end-to-end performance dynamics of commercial cellular networks, or (ii) provide only limited support for running production video-uplink stacks. To bridge the gap between costly on-road trials and the limitations of simulators, we propose CloudEmu, a tracedriven testbed for replaying vehicle video uplink over cellular networks. CloudEmu runs virtual vehicle and video-receiver nodes on commodity Linux-based virtual machines (VMs) and connects them through Linux-based network emulator nodes. This emulator replays field-measured, user-plane endto-end traces of network performance, such as throughput and estimated one-way delay. To achieve realistic network emulation, we further introduce a delay correction method that avoids overestimating the emulated delay. CloudEmu also replays position traces, aligning them by timestamps and tying network dynamics to each position along the route. By capturing cellular and position traces from physical vehicles once per route or test scenario, CloudEmu can repeatedly replay the recorded traces without further on-road driving. CloudEmu offers three advantages. (1) Programmable emulation: CloudEmu reduces testing costs by replaying fieldmeasured, trace-driven user-plane end-to-end network dynamics in a software-defined virtual environment. (2) Reproducibility: Once the traces have been measured, CloudEmu can replay identical conditions, enabling repeatable testing that decouples experimentation from the variability of live cellular deployments. (3) Scalability: CloudEmu is deployable on commodity Linux-based VMs provisioned through infrastructure-as-code, allowing us to scale the number of emulated vehicles and run many experiments in parallel. Our demo deploys the video-uplink stack used in our SAE Level-4 autonomous-driving trials on CloudEmu, including an adaptive video bitrate (ABR) controller [6] and multipath transport [7], to emulate streaming from in-vehicle cameras to a remote video receiver. Attendees can adjust video-delivery parameters and compare the resulting video quality and latency under identical replayed trace conditions, mirroring a tuning process that previously required costly on-road trials.
One Actual Drive Position Traces
Measured Network Quality
Location
Cellular Traces
Network Emulator Node (Sec.Ⅱ-2)
Scenario File (Sec.Ⅱ- 4)
VM Link A Node
(Time-synchronized GPS / Network Traces with Delay Correction) VM
Network Emulator
Vehicle Node (Sec.Ⅱ-1) Multipath Gateway Client
Video Encoder
Video File Video
VM Link B Node
(GStreamer)
Network Emulator
Bitrate Position Emulator
Location
VM
Video-Receiver Node (Sec.Ⅱ-3)
Multipath Gateway Server
Video
Video Decoder (GStreamer)
VM Link C Node
ABR Scheme
Measured & Predicted Network Quality
Network Emulator
Fig. 1. Overview of CloudEmu architecture.
II. P ROPOSED S YSTEM : C LOUD E MU As illustrated in Fig. 1, CloudEmu consists of three node types: Vehicle Node (Sec. II-A1), Network Emulator Node (Sec. II-A2), and Video-Receiver Node (Sec. II-A3). These nodes operate based on an emulation scenario derived from GNSS position and network performance data collected during a real drive (detailed in Sec. II-B). We deploy all nodes as Linux-based virtual machines, provisioned using Terraform1 in an infrastructure-as-code style. This lets us spin up clean environments, tear them down afterward to reduce costs, and run multiple identical setups in parallel. A. Three Node Types in CloudEmu 1) Vehicle Node: This node emulates a vehicle and its onboard video-uplink stack, including a multipath gateway client, an ABR-based video pipeline, and a position emulator. The position emulator publishes GNSS-like coordinates, synchronized with the emulated network conditions, to the Video-Receiver Node. As shown in Fig. 2(a), the vehicle-side GUI visualizes ABR behavior by plotting per-path throughput, delay, and the selected video bitrate over time, enabling developers to inspect how bitrate decisions track network changes along the route. 2) Network Emulator Node: This node represents a cellular path between the Vehicle Node and the Video-Receiver Node, and we instantiate one Network Emulator Node per cellular path. Each emulator runs as a Linux middlebox between the vehicle-side and video-receiver subnets. On each emulator, a traffic-emulation program reads a time-series scenario containing end-to-end link-performance targets (e.g., throughput, delay, and loss) collected using iperf22 during a drive. It periodically updates tc3 on the outgoing interfaces according to the scenario timeline, shaping throughput and adding delay, jitter, and loss to reproduce the observed timevarying user-plane performance along the route. This enables 1 https://developer.hashicorp.com/terraform 2 https://sourceforge.net/projects/iperf2/ 3 https://manpages.ubuntu.com/manpages/xenial/man8/tc.8.html
controlled, repeatable comparisons of transport and application configurations under identical replayed conditions45 . 3) Video-Receiver Node: This node emulates the remote operations center that receives video streams and monitors the vehicles. It runs the receiver-side video-uplink stack, including the multipath gateway server, the video reception pipeline, and the monitoring and logging tools used in our field trials. As shown in Fig. 2(b), the operator can view the received video while replaying the same network traces under different ABR and multipath settings, enabling repeated assessment of operator-side quality of experience (QoE) and of the communication-parameter tuning workflow. B. Emulation Scenario Creation An emulation scenario includes a timestamp, GNSS position (latitude and longitude), and network performance data such as throughput, estimated one-way delay, jitter, and packet loss. 1) Position and Network Traces Alignment: During data collection, the position traces were recorded at 1 Hz, whereas the network traces were sampled every 50 ms. To align the position traces with the 50 ms network samples, intermediate positions are linearly interpolated, producing a time-aligned scenario at 50 ms resolution in which each network-condition sample is paired with a corresponding GNSS coordinate6 . 2) Delay Correction: As introduced in Sec. II-A2, we use tc to reproduce network conditions by shaping throughput and adding delay. However, the delay estimates derived from iperf2 UDP probing already include queuing induced by the measurement traffic. If we feed these values into tc 4 While downlink bandwidth is workload-dependent, prior work has demonstrated that uplink performance is much less sensitive to the workload [8]. Therefore, to emulate end-to-end user-plane throughput and delay dynamics, we use traces measured using iperf2 under a fixed workload. 5 For simplicity, we assume that all paths in the multipath setup are continuously active (e.g., through periodic keep-alive traffic), and we focus on emulating user-plane performance with iperf2 and tc. However, CloudEmu does not reproduce all cellular factors, such as control-plane latency and RANside scheduling effects. Modeling these effects is left for future work. 6 Although linear interpolation can introduce meter-level position errors during turning maneuvers at intersections, these errors are usually smaller than the spatial correlation distance (12–15 m) used in standard spatial-consistency channel models for urban cellular environments [9]. Thus, we expect limited impact on the analysis of replayed user-plane performance at the route level.
(a) Vehicle-side.
(b) Video-receiver-side.
Fig. 2. Example screens on a vehicle-side and video-receiver-side.
2000
Throughput (Emulated) Delay (Measured)
1500
Delay (Emulated)
1000 500 0 0
1
2
3
4
5
Time [s]
6
7
(a) Without correction.
8
Throughput [Mbps]
Throughput (Measured)
11 10 9 8 7 6 5 4 3 2 1 0
Throughput (Measured)
2000
Throughput (Emulated) Delay (Measured)
1500
Delay (Emulated) 1000 500
Delay [ms]
11 10 9 8 7 6 5 4 3 2 1 0
Delay [ms]
Throughput [Mbps]
while also limiting throughput, we double-count queuing and overestimate the emulated delay, especially under heavy load. To address this issue, we propose a congestion-induced delay correction method. It flags intervals where throughput stays below Bth and delay exceeds Dth for at least Tth , then replaces delay and jitter with averages over windows of length Tadj before and after each interval. This way, the queuing delay is primarily introduced by the throughput limit in tc, while the configured delay reflects the baseline propagation component. As a result, the emulated delay more consistently matches the measured end-to-end behavior, even under congestion. We evaluated the emulator using a scenario derived from field measurements that contains a representative congestioninduced delay spike. Using UDP probing with iperf2 (1 Mbps offered load and 50 ms reporting intervals), we compared throughput and estimated one-way delay across (i) the field run, (ii) the emulator driven by the raw scenario, and (iii) the emulator driven by the corrected scenario7 . As shown in Fig. 3, both scenarios reproduce throughput well, but the raw scenario yields inflated and unstable delay estimates after the congestion episode due to double-counted queuing, whereas the corrected scenario tracks the field delay trace more closely.
0 0
1
2
3
4
5
Time [s]
6
7
8
(b) With correction.
Fig. 3. Emulated throughput / delay with and without our correction method.
III. D EMONSTRATION S ETUP We demonstrate trace-driven, route-aware emulation of vehicle video uplink communication on CloudEmu. During the demo, we replay cellular and position traces collected along an urban route in Tokyo, as shown in Fig. 4(a). The cellular trace was collected over three LTE links (from two major mobile operators in Japan) along a 4.8 km route, and was synchronized with the position trace using timestamps (as discussed in Sec. II-B1). In the emulation, we stream prerecorded video instead of live in-vehicle camera footage, enabling controlled comparisons under identical replayed trace conditions. 7B th = 0.7 Mbps, Dth = 50 ms, Tth = 250 ms, Tadj = 1 s
Vehicleside view
40
External monitor
30
VideoReceiverside view
20 10
Laptop
(a) Route map and vehicle speed.
(b) Overview of the demo.
Fig. 4. Overall demonstration setups.
CloudEmu is deployed on Amazon EC28 instances for this demo; during the demo, we use a laptop to access CloudEmu and output both the vehicle-side and video-receiver-side views to an external monitor, as shown in Fig. 4(b). Attendees can adjust ABR and multipath parameters and then compare video quality and latency under identical replayed trace conditions. Specifically, attendees can tune (i) ABR thresholds, including bitrate-selection and delay thresholds, (ii) the multipath gateway packet scheduler, and (iii) retransmission frequency, and observe their impact on video uplink streaming under identical replayed trace conditions. Through this tuning, attendees can experience low-cost, reproducible communication-stack testing that would otherwise require on-road trials. R EFERENCES [1] O. Amador et al., “A survey on remote operation of road vehicles,” IEEE Access, vol. 10, pp. 130 135–130 154, 2022. [2] V. Charpentier et al., “Assessing the impact of CAM messages in vehicular communications in real highway environments,” in Proc. of INFOCOM WKSHPS, 2022. [3] E. Zhang and N. Masoud, “V2XSim: A V2X simulator for connected and automated vehicle environment simulation,” in Proc. of ITSC, 2020. [4] V. Cislaghi et al., “Simulation of tele-operated driving over 5G using CARLA and OMNeT++,” in Proc. of VNC, 2023. [5] A. Elmoghazy et al., “A real-world testbed for V2X in autonomous vehicles: From simulation to actual road testing,” in Proc. of ICFEC, 2024. [6] M. Okada et al., “Video quality control method based on mobile network quality measurements and predictions for reliable remote monitoring in autonomous driving,” in Proc. of VTC2025-Spring, 2025. [7] T. Tojo et al., “Multipath transmission system using multi-layer bandwidth prediction for autonomous driving,” in Proc. of VTC2025-Spring, 2025. [8] W. Sentosa et al., “CellReplay: Towards accurate record-and-replay for cellular networks,” in Proc. of NSDI, 2025. [9] 3GPP TR 38.901 version 19.1.0, “Study on channel model for frequencies from 0.5 to 100 ghz (release 19),” ETSI TR 138 901, 2025. 8 https://aws.amazon.com/ec2/