Intelligent Edge-Cloud Data Management with a Predictive Smart Offloading Proxy for 5G Internet of Vehicles

Abstract

Connected vehicles generate video, sensor, and bulk data that must be uploaded, cached, and forwarded across edge and cloud resources under short contact durations and congested backhaul. This paper studies selected data-management functions of a Smart Offloading Proxy (SOP) for 5G Internet of Vehicles (IoV): deadline-constrained scheduling of uploads already accepted at the edge proxy, and a radio-quality allocation signal. Control-plane functions are described but not evaluated; no end-to-end architecture validation is claimed. For proxy-side forwarding, six bandwidth-scheduling policies are formalized and evaluated in NS-3 against a first-come-first-served serve-one baseline. With bursty arrivals, a 60 Mbps bottleneck, and a 30 s dwell deadline, the shortest-remaining-k equal-allocation policy (SRK-EQ) is the strongest of the six scheduling policies, completing 92.5 ± 4.6% over 20 seeds versus 75.2 ± 12.0% for the all-jobs baseline; the serve-one baseline attains higher completion (98.0 ± 2.4%) for homogeneous 10 MB jobs. Under a heterogeneous 1/10/50 MB workload, SRK-EQ delivers lower latency (median 3.15 s versus 19.84 s) with overlapping completion estimates and a large-job fairness trade-off. In the tested replays, the Long Short-Term Memory (LSTM)-assisted configuration shows lower video and sensor delay with 38–48% lower mean per-flow video throughput than the baseline—a configuration-level latency-versus-throughput trade-off; the LSTM-specific effect is not isolated.

1. Introduction

The widespread adoption of 5G technology is transforming intelligent transportation systems by enabling faster communication among connected vehicles, roadside infrastructure, and cloud services. In 5G Internet of Vehicles (IoV) environments, vehicles continuously generate video, sensor, telemetry, and bulk data that must be uploaded, cached, scheduled, and forwarded across edge and cloud resources. This creates an edge-cloud data management problem rather than only a radio-access problem: vehicular data must be handled under short contact durations, shared network resources, and backhaul congestion. Multi-access Edge Computing (MEC) can bring computation and data-handling functions closer to vehicles, reducing latency and improving service continuity [1,2,3].

During crowded events, peak traffic hours, or dense urban driving, many vehicles may attempt to upload high-rate data streams at the same time. Edge nodes can accept and cache these uploads, but the subsequent edge-to-cloud forwarding stage may still become a bottleneck. If upload jobs are not scheduled effectively, accepted data can miss remote-delivery deadlines even when the vehicle-side interaction has already moved to the edge. Intelligent proxy-side data management is therefore needed to coordinate upload acceptance, backhaul forwarding, and allocation decisions for different traffic classes such as video, sensor, and bulk flows [4,5]. From this perspective, the proxy layer also performs edge-cloud data integration, because vehicular data accepted at edge nodes must be merged into cloud-side storage and services within application deadlines.

This study treats vehicular uploading as an edge-cloud data management problem and builds on the Smart Offloading Proxy (SOP) service, originally proposed for wireless content uploading over crowd events [6]. We improve this original SOP design for the 5G IoV-MEC setting by adding deadline-constrained proxy-side backhaul scheduling, integrating it with MEC, and coupling it, at the design level, with a Long Short-Term Memory (LSTM)-assisted radio-aware allocation signal, thereby extending a single-domain wireless content-uploading proxy into a predictive edge-cloud data-management layer. The proposed SOP layer manages accepted vehicular data by caching and scheduling uploads at edge proxies before remote forwarding. The LSTM component is used as an Artificial Intelligence (AI)-assisted allocation signal rather than as a standalone link-prediction model; therefore, the contribution is an integrated data-handling design—of which selected data-plane functions are evaluated, in separate simulation setups, in this paper—with predictive allocation support, not a general-purpose machine-learning predictor.

The contributions of this work are as follows. First, we present a Smart Offloading Proxy (SOP) design that integrates Smart Offloading Trackers (SOT) and Smart Offloading Servers (SOS) with Content Delivery Network (CDN) and proxy mechanisms; we evaluate selected data-plane functions of this design rather than the full control plane, so SOS selection, handover, and SOT scalability are described but left to future end-to-end study. Second, we formalize and evaluate six proxy-side bandwidth-scheduling policies for deadline-constrained backhaul forwarding, evaluated against a first-come-first-served serve-one baseline (equivalent to earliest deadline first under equal relative deadlines), with 20-seed 95% confidence intervals, a k-window sensitivity sweep, and a heterogeneous 1/10/50 MB workload with a per-size fairness analysis. Third, we characterize an LSTM-smoothed radio-quality signal as a front-end allocation input and quantify the configuration-level latency-versus-throughput trade-off of the LSTM-assisted configuration (which also includes a packet-size adaptation), including the reduction in measured per-flow throughput; we treat this signal as an allocation mechanism, not as a validated link-quality or outcome predictor. Accordingly, the predictive element in the title refers to this predictive allocation support within the proposed data-management design, not to a validated standalone link-quality predictor.

The remainder of this paper is organized as follows. Section 2 reviews related work on 5G vehicular networking, MEC-based offloading, and agent/proxy services, and positions the contribution against this literature. Section 3 describes the SOP architecture, the six bandwidth-scheduling policies, and the radio-aware allocation signal. Section 4 reports the simulation study, covering proxy-side backhaul scheduling (Section 4.1 and Section 4.2) and the 5G New Radio (NR) radio-aware allocation extension (Section 4.3). Section 5 discusses the findings, compares them with prior work, and states the limitations, and Section 6 concludes.

2. Related Work

This section reviews the existing literature in several key areas relevant to our proposed work. First, it examines network performance challenges in 5G vehicular environments, including studies on Transmission Control Protocol (TCP) performance and network saturation issues. Then, it discusses offloading strategies and MEC integration, highlighting recent approaches in distributed computation offloading and resource management. Finally, it addresses the limitations of existing methods and underscores the need for more adaptive solutions.

2.1. 5G Network Performance in Vehicular Environments

The rapid development of 5G technology has significantly advanced vehicular communications, offering higher data rates and lower latency. However, ensuring reliable network performance in high-mobility vehicular environments remains a critical challenge. Patriciello et al. [7] evaluated TCP performance over backpressure-based routing in Long-Term Evolution (LTE) wireless mesh backhaul, demonstrating transport-layer sensitivity to backhaul routing under congestion. Prause and Akselrod [8] analyzed TCP congestion control issues in non-standalone 5G networks, emphasizing the need for adaptable protocols tailored to vehicular contexts. Additionally, Poorzare and Augé [9] discussed the implementation challenges of TCP over 5G networks, highlighting the complexities of maintaining reliable connections in high-mobility environments.

As vehicle connectivity increases, network saturation becomes a pressing issue. Ge et al. [10] demonstrated that 5G network performance can degrade with increasing vehicle density, particularly in urban settings. To mitigate backhaul load, Yu et al. [11] studied millimeter-wave backhaul traffic minimization for coordinated multipoint transmission in 5G cellular networks. Vu et al. [12] investigated joint in-band backhauling and interference mitigation in 5G heterogeneous networks, highlighting the coupling between access interference and backhaul design. Tezergil and Onur [13] surveyed wireless backhaul challenges in 5G and beyond, including capacity, deployment, and architectural issues. Jaber et al. [14] provided a comprehensive analysis of 5G backhaul requirements, stressing the importance of flexible and scalable solutions to meet evolving network demands.

Despite these advancements, current methods often lack adaptability to the rapidly changing conditions characteristic of high-mobility vehicular environments. The dynamic nature of vehicular networks, with frequent changes in topology and network conditions, poses significant challenges that require more responsive and flexible solutions.

2.2. Offloading Strategies and MEC Integration in 5G IoV

Offloading service refers to auxiliary services that help nodes perform their tasks more efficiently. In 5G IoV environments, offloading plays a key role in improving resource usage, computational efficiency, and overall network performance.

Efficient offloading strategies and the integration of MEC are important for optimizing resource usage in 5G IoV environments. Wang et al. [15] proposed a distributed computation offloading scheme for vehicular networks, demonstrating improved resource utilization through deep reinforcement learning (DRL). Seid et al. [16] explored collaborative computation offloading and resource allocation in Internet of Things (IoT) networks assisted by multiple unmanned aerial vehicle (UAV) nodes, indicating the potential for reduced latency in vehicular applications. Ma and Wang [17] investigated distributed offloading in UAV-assisted 5G networks, proposing a framework for aerial-ground integrated vehicular networks that enhances computational efficiency.

Xia et al. [18] developed offloading strategies for cooperative intelligent transportation systems, focusing on optimizing communication efficiency in heterogeneous networks. Zhang et al. [19] introduced a dynamic adaptive multi-objective reinforcement learning approach for computation offloading optimization, showing improved decision-making in complex network scenarios.

For edge computing, Ding et al. [20] proposed an online edge learning offloading scheme for UAV-assisted MEC secure communications, enhancing security and efficiency in aerial-supported networks. Wu et al. [21] explored energy-efficient multi-task offloading using Non-Orthogonal Multiple Access (NOMA) in IoT networks, indicating potential for reduced power consumption in dense network environments. Liu et al. [22] investigated joint offloading and transmission power control for mobile edge computing, proposing strategies to optimize resource allocation. Liao et al. [23] developed a scheme for joint offloading decisions and resource allocation in MEC-enabled networks, aiming to improve overall system performance.

The integration of distributed services has also been explored for efficient task management in 5G IoV. Ye et al. [24] proposed a federated deep learning approach for computation offloading in vehicle clusters, demonstrating improved privacy preservation and computational efficiency. Zeng et al. [25] explored DRL for task offloading and resource allocation, showing adaptive capabilities in dynamic network conditions. Chen et al. [26] applied game theory to distributed computation offloading in multi-server MEC networks, offering insights into strategic decision-making in competitive environments.

However, these techniques often face significant challenges in effectively balancing computational loads and adapting to rapidly changing network conditions inherent in vehicular environments. Existing systems struggle to maintain consistent service quality, particularly in terms of latency and reliability, amid rapid changes in vehicle positions and network loads typical of IoV environments. The high variability in vehicular mobility and network conditions makes it difficult for current offloading strategies to maintain efficiency and effectiveness, especially in high-density and dynamic scenarios.

2.3. Distributed Agent Services in 5G IoV

Most offloading systems incorporate agent services to assist users by managing data processing and communication tasks effectively. The integration of distributed agent services is important for efficient task management and resource allocation in 5G-enabled IoV environments. These agent services typically provide functionalities for efficient data routing, content acceleration, and network monitoring. These capabilities assist in data processing, communication management, and service discovery, which are necessary for maintaining service quality in dynamic vehicular networks.

Prior studies have explored agent-based coordination, proxy deployment, and edge caching to improve IoV performance. These approaches enhance resource management and service reliability but often lack an integrated treatment of offloading, MEC integration, and proxy-based control under high mobility.

Recent studies investigate MEC-enabled resource allocation in IoV [27], social vehicular edge computing for route selection [28], edge security for resource-limited IoT devices [29], probabilistic caching for transient vehicular content distribution [30], and DRL-based task offloading and scheduling in IoV [31]. More recent 2025-2026 work has reframed this layer in terms of AI-driven data management at the edge for intelligent transportation [32], comprehensive reviews of data offloading and edge-cloud architectures for autonomous vehicles [33], LSTM-driven load balancing in MEC for IoV [34], and federated Transformer-based predictive IoV management [35], indicating a shift toward integrated learning-assisted data-handling architectures.

Although significant progress has been made in MEC-enabled offloading and agent services for 5G IoV, existing methods still provide limited treatment of edge-cloud vehicular data management under backhaul congestion. Many approaches focus on computation placement, radio-resource allocation, or caching in isolation, while fewer studies examine how edge proxy nodes should accept, cache, schedule, and forward deadline-constrained vehicular uploads. This gap motivates the proposed SOP framework, which treats proxy-side forwarding and radio-aware allocation as connected functions in a smart transportation data management layer.

Synthesizing the three strands reviewed above, prior work largely optimizes the radio and transport layer, computation and task placement, or agent coordination and caching, while recent learning-assisted schemes improve adaptivity. Beyond offloading proper, recent connected-vehicle research applies predictive and analytics-driven methods to adjacent problems such as privacy- and latency-aware vehicular resource allocation [36], freeway-merging conflict prediction in mixed autonomous traffic [37], and cyber-attack-resilient traffic-flow control [38], reflecting a broader shift toward learning-assisted vehicular systems. What remains comparatively underexplored, and what this paper targets, is the proxy-side data-handling stage: once an edge proxy has accepted vehicular uploads, how it should schedule and forward them over a congested backhaul under a hard dwell deadline.

Table 1. Scope comparison between related work categories and the proposed SOP data-management layer. In the two “Proposed SOP” rows, the marked columns correspond to the data-plane functions evaluated in this paper; SOS selection, handover, control-plane delay, and SOT scalability are design elements not validated end-to-end. The backhaul scheduler and the radio-aware allocation signal were evaluated in separate simulation setups; their end-to-end coupling was not evaluated.

Category	Data Handling	Backhaul	Deadline	Proxy/Cache	AI Allocation
Backhaul [7,8,9,10,11,12,13,14]	Transport/backhaul	✓	△	✗	✗
MEC [15,16,17,18,19,20,21,22,23]	Computation/task placement	△	△	✗	△
Agent/IoV [24,25,26,27,28,29,30,31]	Coordination/caching	△	△	△	✓ DRL/FL
Proposed SOP scheduling	Accepted-upload forwarding	✓	✓ *	Proxy only	✗
Proposed SOP allocation	Radio-aware allocation	—	—	—	✓ LSTM

Notes: ✓, addressed; △, partially addressed; ✗, not addressed; —, outside the module scope. * Deadline handling is implemented only at the edge proxy and does not constitute an end-to-end guarantee. DRL, deep reinforcement learning; FL, federated learning; LSTM, long short-term memory.

maps each strand to this gap and to the specific problem addressed here.

Based on this gap, this research proposes a SOP service that integrates adaptive SOS bandwidth scheduling with MEC and an LSTM-derived radio-aware allocation signal. The resulting architecture is positioned as an edge-cloud vehicular data-management layer for deadline-constrained uploads rather than as a general-purpose radio-access or machine-learning system.

3. Methods

3.1. Smart Offloading Services for 5G IoV with MEC

To address the challenges of 5G IoV and MEC environments, we propose the SOP service. SOP integrates CDN principles and proxy mechanisms to improve the user experience during data uploading. Additionally, we incorporate Peer-to-Peer (P2P) tracker mechanisms to efficiently manage edge nodes in our system.

In the 5G IoV environment, MEC plays an important role in ensuring efficient data processing close to the edge. By deploying SOP with MEC, the system can efficiently handle the data uploading process, particularly in scenarios involving high vehicle density, by selecting appropriate offloading servers to optimize resource usage and reduce latency. Figure 1a shows how pairing information is negotiated with the SOT.

The hypothesis is that network utilization in high-traffic vehicular environments can be improved if vehicles complete their uploading tasks quickly, thus reducing overall load on the system. To validate this, we implemented an NS-3 simulation model of the proposed SOP system, which includes various scheduling schemes to allocate bandwidth for reducing file upload time. Figure 1b illustrates the connection and uploading process with a suggested SOS.

An SOP service consists of multiple offloading trackers and servers to efficiently manage data flow and improve the quality of service. Figure 2 summarizes the overall working flow of the 5G-IoV smart offloading service.

3.1.1. Smart Offloading Tracker

The SOT is responsible for selecting appropriate SOS nodes for vehicles. The SOT records information about SOS nodes, such as geolocation, current load, and bandwidth capacity. When a vehicle initiates an upload request, the SOT analyzes network conditions and selects an optimal SOS for that particular vehicle, as shown in Figure 3.

The SOT system can be extended to a distributed hierarchical architecture to increase scalability and robustness, similar to CDNs and the Domain Name System (DNS). This distributed model allows local SOTs to manage specific regions while a global SOT maintains information about all local nodes, thereby mitigating the risk of system overload during high traffic events (Figure 4). The procedures shown in Figure 2, Figure 3 and Figure 4—SOS connection, NEI collection, SOT-based selection, and hierarchical coordination—are control-plane functions; they are described at the design level and are not evaluated in Section 4.

3.1.2. Smart Offloading Server

The SOS functions as an intelligent edge caching system in the 5G Vehicle-to-Everything (V2X) environment, temporarily storing uploaded data to reduce latency and improve network efficiency. By integrating with MEC infrastructure and positioning close to vehicles, it reduces the Round-Trip Time (RTT) and increases throughput. The SOS handles vehicle uploads by caching data locally before transmitting it to the target server, thus minimizing the impact of long-distance transmission on the user’s experience, as illustrated in Figure 5.

In contrast to traditional base stations, which often face competition for resources among multiple vehicles, the SOS implements sophisticated bandwidth allocation strategies to optimize resource utilization. The SOS employs six different scheduling methods to prioritize vehicular uploading tasks, ranging from equal bandwidth distribution to selection- and remaining-work-based allocation schemes. These bandwidth management approaches are designed to sustain efficient network utilization in high-density environments, as illustrated in Figure 6; their measured effect is evaluated in Section 4. The six scheduling methods are formalized in Section 3.2, and the predictive LSTM-based radio-quality signal that supports allocation—including its input features, training target, and hyperparameters—is detailed in Section 3.3 and Section 4.3.1.

3.1.3. MEC Integration

The integration of MEC in the SOP service enhances its capabilities by providing computational resources close to the edge. This reduces the need for data to travel to distant cloud servers, thus lowering latency and improving real-time data processing for 5G-enabled IoV environments. MEC nodes primarily handle time-critical vehicular tasks such as real-time trajectory prediction, collision avoidance calculations, emergency brake warnings, and cooperative lane change coordination. These computations require immediate processing and feedback to vehicles for safe operation. Meanwhile, SOS manages two types of data transmission tasks: processed results from MEC that need to be shared with other vehicles in the vicinity, and non-time-critical data (such as entertainment content, road condition updates, and traffic statistics) that need to be uploaded to cloud servers or shared through P2P networks. These task categories are conceptual design targets for the architecture; the scheduler evaluated in Section 4 uses a single traffic class without priority differentiation.

The system architecture is designed with the potential to support frequency band adaptation in future implementations. For example, different types of vehicular data could be transmitted through appropriate frequency bands based on their characteristics: safety-critical messages could utilize more reliable frequency bands, while bulk data transfers could use higher frequency bands with greater bandwidth capacity. In the current implementation, SOS focuses on intelligent bandwidth allocation strategies to ensure efficient data distribution based on the job-selection and remaining-work rules of Section 3.2. The MEC nodes work in tandem with SOS to manage data flow, optimize bandwidth allocation, and ensure critical information is processed and delivered promptly. Figure 7 summarizes the resulting MEC and SOS integration for task classification and data-flow management.

3.2. Bandwidth Scheduling Strategies

To improve vehicle experience during file uploading, we implement several bandwidth scheduling strategies in the SOS nodes. In vehicular networks, data uploading tasks present diverse requirements depending on traffic conditions and application types. While our current implementation focuses on evaluating general performance, these methods are designed with potential vehicular network scenarios in mind. Each method is named by its job-selection rule (ALL: all jobs; SK: the k jobs with the shortest execution time; SRK: the k jobs with the shortest remaining time) combined with its bandwidth-allocation policy (EQ: equal bandwidth; LRF: longest-remaining-first):

ALL-EQ (All Jobs, Equal Bandwidth): Theoretically suitable for scenarios where vehicles have similar priority levels, such as regular status updates or environmental sensing data uploads in stable traffic conditions.

ALL-LRF (All Jobs, Longest-Remaining-First): Primarily designed for situations involving large-volume data uploads like high-definition maps or traffic video footage, aiming to prevent indefinite postponement of time-consuming tasks.

SK-EQ (Shortest-k Jobs, Equal Bandwidth): Potentially effective for managing burst uploads in dense traffic areas, such as intersection video feeds or multiple vehicle sensor data, by focusing on quickly completing smaller tasks.

SK-LRF (Shortest-k Jobs, Longest-Remaining-First): Proposed for mixed traffic scenarios where both emergency messages and regular updates need to be managed, balancing immediacy with fairness.

SRK-EQ (Shortest-Remaining-k Jobs, Equal Bandwidth): Conceptually useful in crowded urban environments where completing quick tasks efficiently can help reduce overall network congestion.

SRK-LRF (Shortest-Remaining-k Jobs, Longest-Remaining-First): Designed for complex traffic scenarios involving both time-critical safety messages and routine data uploads, aiming to ensure efficient resource utilization while maintaining fair access. The application examples in these descriptions are conceptual deployment scenarios; the evaluated suite uses a single traffic class without priority labels or class-dependent deadlines (Section 4).

Summary of Scheduling Methods

The six bandwidth scheduling methods combine two allocation policies and three job selection strategies. The two allocation policies are equal bandwidth allocation (EQ) and prioritization based on longest-remaining-first allocation (LRF). The three job selection strategies include selecting all jobs (ALL), selecting the k shortest jobs based on execution time (SK), and selecting the k shortest jobs based on remaining time (SRK).

Table 2. Summary of bandwidth scheduling methods.

Job Selection Strategy	Bandwidth Allocation Policy
	EQ: Equal Bandwidth	LRF: Longest-Remaining-First
ALL: Select All Jobs	ALL-EQ	ALL-LRF
SK: Select up to k Jobs with Shortest Execution Time	SK-EQ	SK-LRF
SRK: Select up to k Jobs with Shortest Remaining Time	SRK-EQ	SRK-LRF

provides a summary of the methods.

To formalize the scheduling methods, let J be the set of upload jobs, where each job has an estimated execution time and a remaining processing time. The selected set K is determined by one of three job-selection rules, with m = min(k, |J|) so that the selection is well defined when fewer than k jobs are active, and bandwidth is then assigned using either equal sharing or longest-remaining-first allocation. The primary comparisons in Section 4.1 and Section 4.2 use k = 5; Section 4.2.2 additionally evaluates sensitivity over k ∈ {1, 3, 5, 7, 10}.

$$K_{all}=J$$

(1)

$$K_{time}\in arg\underset{K\subseteq J,\left|K\right|=m}{min}\sum _{j\in K}{t}_j$$

(2)

$$K_{rem}\in arg\underset{K\subseteq J,\left|K\right|=m}{min}\sum _{j\in K}{r}_j$$

(3)

$$B_j=\left\{\begin{array}{c}{\displaystyle \frac{B_{total}}{\left|K\right|}},j\in K\\ 0,j\notin K\end{array}\right.$$

(4)

$$B_j=\left\{\begin{array}{c}{B}_{total},j=j^{\ast }\\ 0,otherwise\end{array}\right.$$

(5)

Equations (1)–(5) define the scheduling primitives used by the six scheduling methods. Equations (1)–(3) specify the all-job, shortest-execution-time, and shortest-remaining-time job-selection sets. Equation (4) defines equal bandwidth sharing among the selected jobs, whereas Equation (5) serves a single selected job $j^{\ast }$at the full link rate in each scheduling interval, where$j^{\ast }$is the first job attaining the maximum remaining work in the order in which the scheduler stores the selected jobs—arrival order under ALL selection, the order produced by the sorting step that implements Equations (2) and (3) otherwise—so the Equation (5) service tie-break is deterministic for a given build and seed. Under Equation (4), jobs outside the selected set receive no bandwidth in that interval; under Equation (5), all jobs other than $j^{\ast }$receive none. Equations (1)–(5) are standard scheduling primitives in the processor-sharing and shortest-remaining-processing-time (SRPT) lineage [39]; they were formulated directly for this proxy setting rather than adapted from a specific prior implementation. The LRF label denotes this per-interval longest-remaining-first service within the selected set: in each scheduling interval, the selected job with the largest remaining work receives the full link rate (Equation (5)). Job selection sorts by total or remaining size without an explicit secondary key, so the order among identical sizes is implementation-defined by the sorting routine rather than arrival-ordered; because the simulation is deterministic for a given build and seed, each reported run is exactly reproducible; under equal allocation the selected jobs progress together; the SK sort keys are static total sizes, and under the shortest-remaining rule the selected jobs retain smaller remaining sizes than unselected jobs, so the selected set remains stable between arrival and completion events. For the serve-one baseline, arrival-time ties resolve to job-insertion order.

3.3. LSTM-Assisted Radio-Aware Allocation Signal

The baseline SOP decision uses the distance-based connectivity score in Equation (6):

$$score=max\left(\mathrm{0,1}-{\displaystyle \frac{d}{d_{max}}}\right)$$

(6)

where d is the distance to the closest next-generation NodeB (gNB) and the maximum-distance threshold is 500 m. Vehicles are marked as poor when the score is below 0.4 (hysteresis 0.5), which triggers MEC offloading. For link-quality-aware allocation, we train an LSTM model on radio traces to provide a short-term link-quality signal for SOP allocation. The weighted radio score is defined over Reference Signal Received Power (RSRP), Signal-to-Interference-plus-Noise Ratio (SINR), Reference Signal Received Quality (RSRQ), and Channel Quality Indicator (CQI) measurements with exponentially weighted moving average (EWMA) smoothing; the LSTM uses an input sequence length of 3 and 16 hidden units, with a narrower deployed input configuration (Section 4.3.1): CQI is unavailable in the collected traces, RSRQ is constant, and SINR was not part of the deployed checkpoint’s input configuration. Training targets are derived from a weighted radio score on normalized measurements with bias 0.1 and default weights 0.4 for RSRP, 0.3 for SINR, 0.1 for RSRQ, and 0.2 for CQI. The predicted trace is injected into NS-3. In the allocation-injection configuration, the LSTM score affects only the bulk allocation factor, while the MEC/remote decision remains driven by the radio-based decision score; the designation refers only to the signal-injection point and does not denote a matched allocation-only ablation, because the packet-size adaptation described below also differs between the SOP and SOP+LSTM configurations. The weighted-score coefficients are a design choice that emphasizes received power and SINR in a smoothed allocation target; they are not tuned parameters of a validated predictor.

The LSTM trace is sampled at the SOP update interval and smoothed with EWMA before allocation updates; a decision-hold time is applied to prevent rapid MEC/remote switching. We emphasize that this LSTM is a signal-conditioning module: its training target is the defined weighted radio score above (a smoothed function of the design features RSRP/SINR/RSRQ/CQI; the deployed target is narrower, Section 4.3.1), not measured throughput, delay, or completion, so it is used as an allocation signal rather than a validated link-quality or outcome predictor. In the available NR traces RSRQ and CQI are largely uninformative (RSRQ constant, CQI unavailable) and each per-user-equipment (UE) trace spans only a few update intervals, so a full predictor validation with held-out error metrics against EWMA, moving-average, and regression baselines is deferred to future work with richer traces (Section 5.3).

4. Results

This section evaluates SOP data handling along the upload path. Section 4.1 and Section 4.2 first examine SOS backhaul forwarding: after uploads are accepted at the edge proxy, the SOS must decide which jobs receive the bottleneck bandwidth so that remote delivery can finish within the dwell-time budget. These experiments use a simplified NS-3 scheduler suite (five seeds for the Section 4.1 robustness check; 20 seeds for the Section 4.2 policy comparison) to isolate queue buildup, deadline completion, and policy differences under controlled congestion. Section 4.3 then moves one step earlier in the SOP workflow and examines AI-assisted radio-aware allocation, using an LSTM-derived link-quality signal to tune allocation under 5G New Radio (NR) traces. The evaluation is therefore organized around two connected SOP data-management functions: proxy-side backhaul forwarding and radio-aware allocation.

4.1. Robustness Check Under Four Backhaul Conditions

Simulation Setup

The scheduler experiment is designed to answer a narrow question: how an SOS should forward accepted uploads over a congested SOS-to-remote backhaul. In the service architecture, a vehicle upload can be accepted at the SOS before remote forwarding. In the experiments reported here, however, completion is defined more strictly as target-server receipt before the 30 s dwell-time budget. This definition stress-tests the backhaul scheduler and should not be read as a full vehicle-to-SOS radio-access, handover, or SOT-selection model.

The simulation setup follows the topology of Figure 1b. We use the NS-3 network simulator and a simplified SOP model that abstracts radio access and focuses on the SOS-to-remote backhaul, configured as a 60 Mbps bottleneck. Upload jobs arrive according to a Poisson process with a baseline rate of 0.5 jobs/s, and a congestion period increases the rate to 2.0 jobs/s between 15 s and 30 s. Each job size is fixed at 10 MB. The simulation runs for 60 s and uses a 30 s dwell deadline as a scheduler budget. Arrivals stop at 60 s, and service continues until every pending job completes or reaches its deadline (approximately 90 s at the latest), which is why the time axes of the active-job plots extend beyond 60 s. Each case is repeated with five random seeds and averaged.

The propagation delay was set at two levels: 0 ms and 50 ms, representing ideal and congested backhaul conditions, and the packet loss rate was set at either 0 or 0.01, resulting in four scenarios as described in

Table 3. Network condition scenarios in simulation.

Scenario	Propagation Delay	Packet Loss Rate
Case 1	0 ms	0
Case 2	0 ms	0.01
Case 3	50 ms	0
Case 4	50 ms	0.01

. The SOT process, SOT selection accuracy, control-plane delay, SOS buffer limit, and vehicle-to-SOS radio link are not modeled in this scheduler suite. This isolation lets the experiment compare SOS data-plane scheduling policies; it leaves SOT scalability, load-balancing overhead, and failure cases to future integrated evaluation. We compare the baseline scheduler (the all-jobs equal-share policy, ALL-EQ in Table 2) against SOP scheduling with SRK-EQ (k = 5).

Figure 8 shows the average number of active upload jobs over time (mean of five seeds). SOP (SRK-EQ) consistently reduces queue buildup versus the baseline scheduler across all network conditions, indicating faster service during the congestion window.

Figure 9 and Figure 10 show completion-time distributions with deadline drops retained in the accounting. Figure 9 places dropped jobs at the 30 s dwell deadline, while Figure 10 plots completed jobs with all generated jobs retained in the cumulative distribution function (CDF) denominator. Across all cases, the completed-upload median decreases from 20.1 s (baseline) to 11.3 s (SOP SRK-EQ), and the 95th-percentile completion time (p95) decreases from 29.5 s to 26.0 s. The overall completion ratio (completed/total) increases from 70.9% to 94.3%, indicating fewer deadline misses under heavy load in the controlled backhaul model. Because all four backhaul cases use the same 10 MB job size and 30 s dwell deadline, the completion-ratio summary is dominated by service-ordering effects; propagation delay and the tested loss rate mainly affect queue evolution rather than changing the deadline outcome. We therefore read this section as a robustness check of the forwarding stage under varying backhaul conditions rather than as a differentiating comparison; a wider delay, loss, and capacity sweep that separates the four cases is left to future work (Section 5.3).

The results show that SOP scheduling reduces queue buildup and improves completion ratios under heavy load in the five-seed scheduler suite.

4.2. Evaluation of Bandwidth Scheduling Strategies

To understand the impact of various bandwidth scheduling strategies implemented in SOS, we measured the performance of each method in the controlled SOS-to-remote backhaul model. The goal was to determine the effectiveness of each strategy in optimizing resource allocation and minimizing upload times for vehicles under different traffic conditions.

We reuse the sop-sim model with a fixed backhaul delay of 50 ms and loss rate 0.01 to emulate congested core conditions. The bottleneck capacity is 60 Mbps. Upload job arrivals follow a Poisson process with a baseline rate of 0.5 jobs/s and an event-period rate of 2.0 jobs/s during 15–30 s; the simulation time is 60 s. Job size is fixed at 10 MB and the dwell deadline is 30 s. Each of the six methods is run with 20 random seeds; results are averaged, and Section 4.2.2 reports the corresponding confidence intervals and significance tests.

4.2.1. Analysis Results

Figure 11 and Figure 12 show the cumulative completed fractions and active queue dynamics for the six scheduling methods. Over the 20 seeds, SRK-EQ achieves the highest completion ratio among the six proposed policies (92.5 ± 4.6%), followed by SRK-LRF (86.4 ± 6.3%) and SK-EQ (83.3 ± 7.3%); ALL-EQ and ALL-LRF reach 75.2 ± 12.0% and 46.6 ± 8.7%, respectively, while SK-LRF reaches 71.2 ± 7.3%. Among completed uploads, the mean per-seed medians are 9.4–12.8 s for the four k-limited methods (SK-EQ, SK-LRF, SRK-EQ, and SRK-LRF), compared with 17.9 s for ALL-EQ. ALL-LRF has an 11.9 s completed-upload median but drops more jobs, so its lower median reflects a smaller completed subset.

SK-EQ, SRK-EQ, and SRK-LRF are more suitable for managing upload tasks within a 30 s dwell deadline in this controlled backhaul model because they prioritize shorter or shorter-remaining jobs and improve completion ratios. SRK-EQ also has the lowest mean active queue and peak queue in the 20-seed scheduling suite. Because initial job size is fixed at 10 MB, SRK-EQ’s advantage should be interpreted as queue-state and k-window selection behavior rather than a complete validation of short-job fairness across heterogeneous file sizes.

Overall, the results indicate that adaptive bandwidth scheduling strategies, particularly SK-EQ, SRK-EQ, and SRK-LRF, improve deadline completion under congestion. Completion-time medians must be interpreted together with final CDF values because dropped jobs remain in the denominator. These findings identify how the SOS should forward accepted uploads over the backhaul; Section 4.3 examines how SOP can use radio-quality information to tune allocation before traffic enters this forwarding stage.

4.2.2. Statistical Robustness, a Serve-One Baseline, k-Sensitivity, and Heterogeneous Sizes

To strengthen the statistical treatment and baseline coverage, the six-policy comparison uses 20 random seeds; we report the mean completion ratio with a Student’s t-based 95% confidence interval (CI; ± denotes the half-width throughout): SRK-EQ 92.5 ± 4.6%, SRK-LRF 86.4 ± 6.3%, SK-EQ 83.3 ± 7.3%, SK-LRF 71.2 ± 7.3%, ALL-EQ 75.2 ± 12.0%, and ALL-LRF 46.6 ± 8.7%. The five-seed results of the Section 4.1 robustness suite are consistent with these intervals.

Table 4. Twenty-seed statistics for the serve-one baseline and the six scheduling policies (homogeneous 10 MB workload): completion ratio and completed-upload median and p95 (mean ± 95% CI half-width across seeds).

Policy	Completion (%)	Median (s)	p95 (s)
FCFS (serve-one)	98.0 ± 2.4	13.3 ± 2.2	22.7 ± 2.8
ALL-EQ	75.2 ± 12.0	17.9 ± 2.1	26.6 ± 2.4
ALL-LRF	46.6 ± 8.7	11.9 ± 2.8	25.1 ± 2.1
SK-EQ	83.3 ± 7.3	9.4 ± 1.6	23.2 ± 2.8
SK-LRF	71.2 ± 7.3	12.8 ± 1.0	26.5 ± 2.3
SRK-EQ	92.5 ± 4.6	10.5 ± 1.2	23.3 ± 2.4
SRK-LRF	86.4 ± 6.3	11.5 ± 1.7	24.8 ± 2.2

summarizes the completion, median, and p95 statistics for all seven policies. We further add a first-come-first-served serve-one baseline (FCFS) that serves the single oldest job at the full backhaul rate; because each job has the same 30 s relative deadline—its absolute deadline is its own arrival time plus 30 s—deadline order coincides with arrival order, so FCFS also realizes an earliest-deadline-first (EDF) [40] discipline here; and because all jobs belong to a single traffic class, priority first-in-first-out (priority-FIFO) likewise reduces to FCFS in this setting. With homogeneous 10 MB jobs, FCFS attains the highest raw completion (98.0 ± 2.4%; paired t-test versus SRK-EQ, p = 0.001) because it combines full-rate single-job service with arrival-aligned—hence deadline-aligned—ordering; unlike the LRF variants, it never starves a nearly finished job in favor of the largest remaining one; its confidence interval marginally overlaps SRK-EQ’s (the paired test is nevertheless significant because the same seeds are shared across policies), and even with homogeneous sizes the completed-job median remains lower under SRK-EQ (10.5 s versus 13.3 s for FCFS). A paired t-test on the per-seed completion ratios over the 20 shared seeds confirms SRK-EQ’s advantage over the all-jobs baseline (p < 0.001). SRK-EQ is therefore the strongest of the six proposed scheduling policies, whereas the FCFS serve-one baseline attains the highest raw completion when job sizes are identical; the advantage of the proposed policies appears in latency and, as shown next, under heterogeneous sizes. The ordering is also robust to the bottleneck capacity: repeating the homogeneous suite at 30 and 120 Mbps leaves the relative ordering unchanged at 30 Mbps (SRK-EQ 50.5 ± 4.1% versus 21.8 ± 3.4% for the all-jobs baseline, with FCFS at 53.0 ± 5.1% overlapping SRK-EQ’s interval), while at 120 Mbps the bottleneck stops binding and the policies converge (all reach 100%).

Because the k-window defines four of the six policies, we swept k ∈ {1, 3, 5, 7, 10} over 20 seeds. The mean completion ratio decreases monotonically with k for every k-window policy (SRK-EQ: 95.8 ± 3.2% at k = 1, 92.5 ± 4.6% at k = 5, 88.5 ± 4.9% at k = 10; SK-EQ: 94.3% at k = 1 falling to 78.7% at k = 10). For the EQ policies, a smaller k increases the bandwidth share received by each selected job, consistent with shortest-remaining-processing-time (SRPT) behavior; for the LRF policies, k changes only the candidate set from which the largest-remaining job is drawn, while service remains limited to one job per scheduling interval. Thus k acts as a concurrency window for the EQ policies and as a selection window for the LRF policies. The completed-job median is non-monotone in k (11.4 s at k = 1, 10.0 s at k = 3, 10.5 s at k = 5, 13.1 s at k = 10), so intermediate windows also serve latency; we use k = 5 as a representative intermediate selection window—in the EQ variants it permits up to five jobs to make concurrent progress while retaining most of the completion benefit—rather than as an empirically optimal value.

Because a fixed 10 MB workload cannot expose the fairness behavior of shortest-remaining policies, we repeated the comparison with a heterogeneous mix of 1/10/50 MB jobs, each job’s size drawn independently and uniformly from these three values (20 seeds). Under the tested 1/10/50 MB mix, six of the seven policies cluster between 71.2% and 75.9% completion (SRK-LRF 75.9 ± 4.8%, SRK-EQ 75.1 ± 3.8%, SK-EQ 74.7 ± 3.9%, FCFS 73.7 ± 6.6%, ALL-EQ 72.0 ± 5.7%, SK-LRF 71.2 ± 5.5%), whereas ALL-LRF remains substantially lower at 22.7 ± 5.5%; among the clustered policies, the confidence intervals overlap substantially, so we do not claim a clear completion winner. However, the equal-allocation shortest-remaining and shortest-k policies deliver markedly lower latency, while their longest-remaining-first variants trade latency for large-job fairness: the median completed-upload time (mean of per-seed medians) is 3.15 ± 1.16 s for SRK-EQ versus 19.84 ± 2.49 s for FCFS and 4.40 ± 1.49 s for ALL-EQ, and the p95 is 15.5 ± 2.8 s for SRK-EQ versus 29.3 ± 0.7 s for FCFS. Each median is computed over that policy’s own completed set, which for SRK-EQ under-represents 50 MB jobs (per-size breakdown below). A paired t-test on the per-seed median latencies over the 20 shared seeds confirms the advantage over FCFS (p < 0.001); the paired t-test detected no significant difference between SRK-EQ and SK-EQ (mean difference 0.01 s, p = 0.29; a Wilcoxon signed-rank test on the same pairs reaches p = 0.043, but the 0.01 s effect is practically negligible). A per-size breakdown shows the expected trade-off: SRK-EQ completes 100% of 1 MB and 10 MB jobs but only 22 ± 6% of 50 MB jobs (large-job starvation), whereas SRK-LRF is more balanced (38 ± 9% of 50 MB jobs) at a latency cost. These results confirm that the shortest-remaining-k policies optimize small- and medium-job latency under mixed sizes, that the SRK-LRF variant improves large-job completion at a latency cost, and that the policies should be read as latency and fairness mechanisms rather than universal completion maximizers.

4.3. Radio-Aware SOP Allocation Extension

The preceding sections evaluate the forwarding stage of SOP, where SOS nodes schedule accepted jobs over a congested backhaul. SOP operation also depends on allocation decisions made under changing radio conditions before those jobs enter the forwarding stage. To evaluate this allocation layer, we integrate the LSTM-based link-quality signal (Section 3.3) in the allocation-injection configuration—the designation refers only to the signal-injection point (the bulk allocation factor), not to a matched allocation-only ablation, because the packet-size adaptation also differs between the configurations (Section 4.3.1)—and compare four policies: (1) SOP baseline (distance-based connectivity threshold), (2) SOP+LSTM, (3) Always MEC, and (4) Always Remote. SOP+LSTM uses the LSTM trace to set the allocation factor, while MEC/remote switching follows the radio-based decision score.

4.3.1. Radio-Aware Allocation Simulation Setup

The simulation uses 5G NR with 2 gNBs, 1 MEC node, and 1 remote host. The proxy-side scheduling experiments in Section 4.1 and Section 4.2 used NS-3 version 3.42, whereas the NR allocation experiments in this section used an NS-3 development build with a 5G-LENA NR v3.3-based module. The carrier is 3.5 GHz with 40 MHz bandwidth and Proportional Fair (PF) scheduling. Vehicles are modeled as User Equipment (UEs) and move along a 1000 m highway at 30 m/s with maxRange = 500 m. Each UE generates three flows: video over User Datagram Protocol (UDP) at 6 Mbps (packet size 1400 bytes, reduced to 600 bytes under poor connectivity), sensor UDP at 200 Kbps (96 bytes), and bulk TCP at 10 Mbps (1200 bytes). The MEC one-way delay is 2 ms and the core one-way delay is 20 ms. SOP updates run every 5 s with thresholds 0.4/0.5 and minimum allocation factor 0.6; allocation updates use a 0.05 delta threshold and a 1 s decision-hold time. The LSTM model uses sequence length 3 and 16 hidden units and is trained on radio traces before generating the allocation signal used in NS-3. Results are reported for UE counts {8, 10, 20, 30}; the evaluation is intentionally confined to 30 UEs and below, as higher counts triggered an NR Radio Network Temporary Identifier (RNTI) assertion in the current NS-3 setup.

The allocation-signal model is implemented in PyTorch 2.4.1 (Python 3.12.3, NumPy 2.4.1) as a single-layer LSTM (16 hidden units, input sequence length 3) followed by a linear layer with sigmoid output, trained with full-batch Adam (learning rate 0.01, mean-squared-error loss, 60 epochs, no early stopping). Inputs are EWMA-smoothed radio measurements normalized to [0, 1] by fixed global ranges (RSRP [−120, −60] dBm; RSRQ [−20, −3] dB; SINR [−5, 25] dB); CQI is unavailable in the collected traces and is excluded from the model input, and RSRQ is constant in these traces, so the deployed input reduces to the smoothed RSRP and RSRQ sequences—effectively RSRP-driven, since the constant RSRQ carries no information. The one-interval-ahead training target is y(t + 1) = clip[(0.4·RSRP + 0.1·RSRQ)/0.5 + 0.1, 0, 1] on the min-max-normalized EWMA features (input smoothing factor 0.6, the same value as the runtime smoothing below); because normalized RSRQ is constantly 1, the effective deployed target is clip(0.8·RSRP + 0.3, 0, 1), and SINR appears neither in the deployed input nor in the deployed target (it belongs only to the four-feature design definition of Section 3.3). Training uses the seed-1 and seed-2 radio traces (ten traces across the five UE counts {6, 8, 10, 20, 30}, each per-UE series spanning five 5 s update points; 296 sequences (148 per-UE series × two one-step-ahead windows per series); 80/20 train/validation shuffle with fixed seed 42; network initialization was not seeded; the exact checkpoint used for the reported simulations is retained and reproduces the deployed inference traces, although the original stochastic training initialization is not repeatable); because adjacent length-3 windows overlap, this split serves only for training-loss monitoring and is not an independent validation. The seed-3 traces are held out and used only to generate the per-UE score traces injected into NS-3; Figure 13, Figure 14 and Figure 15 report a single seed-3 replay per UE count, which is why no error bars are shown. At runtime the score s is EWMA-smoothed (smoothing factor 0.6) and mapped linearly to the bulk allocation factor a = 0.6 + 0.4·s, clamped to [0.6, 1] and reapplied only when it changes by more than 0.05; the MEC-versus-remote decision, the poor-connectivity marking (enter below 0.4, exit above 0.5, 1 s decision hold), and the packet-size adaptation remain driven by the radio-based decision score. The factor a scales only the bulk TCP sending rate; video and sensor rates are not scaled by a. The video-side differences in Section 4.3.2 arise primarily from ML-mode operation—most directly the packet-size adaptation (1400 → 600 bytes under radio-based poor marking), together with the destination switching reflected in the per-flow accounting—which is active in the SOP+LSTM runs but not in the SOP baseline runs, which execute without the ML module.

4.3.2. Performance Comparison of SOP and SOP+LSTM

Table 5. Macro-average performance across reported UE counts in the NR allocation experiment.

Policy	Video		Sensor		Bulk
	Mean Per-Flow Throughput (Mbps)	Mean Per-Flow Delay (s)	Mean Per-Flow Throughput (Mbps)	Mean Per-Flow Delay (s)	Mean Per-Flow Throughput (Mbps)	Mean Per-Flow Delay (s)
SOP	1.068	1.258	0.128	0.707	1.124	0.063
SOP+LSTM	0.639	0.668	0.111	0.592	1.000	0.058
Always MEC	1.199	1.409	0.138	0.612	1.516	0.037
Always Remote	1.182	1.454	0.137	0.683	0.698	0.111

summarizes macro averages across UE counts in the radio-aware allocation evaluation, while Figure 13 and Figure 14 show the corresponding per-UE-count trends. SOP+LSTM shows lower delay for video and sensor flows and a small bulk-delay reduction, while reducing throughput across all flows. Because the SOP+LSTM configuration differs from the SOP baseline in both the bulk allocation signal and the packet-size adaptation, these results represent a configuration-level latency-versus-throughput trade-off and do not isolate an LSTM-specific causal effect; the affected traffic is primarily latency-sensitive video and sensor flows rather than throughput-oriented bulk transfer.

The comparison is therefore interpreted as a combined configuration-level latency-versus-throughput trade-off, rather than as evidence that the LSTM allocation signal alone benefits video or sensor flows. Because a lower absolute video throughput could reflect delivering less data rather than a like-for-like latency gain, we examined delivery. Measured packet loss is negligible (LostPackets ≈ 0 across runs), so the throughput differences reflect the offered and allocated sending rate—including the 1400 → 600 byte packet-size adaptation under poor connectivity—rather than link loss. Throughput is computed per monitored flow as delivered bytes over that flow’s active span and averaged within each traffic class, and delay is likewise a per-flow mean averaged within each class; because ML-mode destination switching splits a user’s traffic across multiple monitored flows, the per-flow class means under SOP+LSTM also reflect this flow accounting, and the smaller sensor-side reduction in Table 5 may likewise partly reflect this flow splitting and the per-flow accounting itself rather than packet loss (sensor LostPackets = 0 in both configurations). The delivery ratio of monitored transmitted packets is therefore approximately 100%. Relative to the nominal 6 Mbps source rate, the Table 5 per-flow video means correspond to 17.8% for SOP and 10.7% for SOP+LSTM; because destination switching fragments SOP+LSTM traffic across monitored flows with differing active spans, these per-flow statistics are not interpreted as per-UE delivered-bitrate or delivery-ratio estimates. Relative to the SOP baseline, SOP+LSTM shows 38–48% lower mean per-flow video throughput across the tested UE counts (computed per UE count from the paired SOP and SOP+LSTM runs of this section, for example 1.79 → 1.04 Mbps at 10 UEs and 0.084 → 0.044 Mbps at 30 UEs; Table 5 reports the corresponding macro-averaged summary) while lowering video delay; the lower measured per-flow throughput is consistent with the reduced offered video load under the ML-mode packet-size adaptation (Section 4.3.1), although the per-flow accounting does not quantify the aggregate per-UE delivered-rate reduction, whereas the allocation factor itself rescales only the bulk flow. Because the two configurations therefore differ in more than the allocation signal, the comparison characterizes a combined configuration-level trade-off and does not isolate the causal effect of the LSTM signal. At high UE counts the measured per-flow video rate falls well below the 6 Mbps offered rate for all policies (a shared-capacity effect; the baseline’s per-flow mean corresponds to only about 4% of the offered video rate at 20 UEs); because these per-flow values are not aggregate per-UE delivered rates and the simulation includes no codec or video-quality model, we make no claim about residual-stream usability. We therefore present SOP+LSTM as a latency-versus-throughput trade-off for latency-sensitive classes that can operate at a reduced delivery rate, not as a cost-free latency improvement.

4.3.3. Comparison with Always MEC/Remote

Figure 15 compares SOP+LSTM with Always MEC and Always Remote in the same NR setting. Always MEC yields the lowest bulk delay and highest bulk throughput but increases video delay; Always Remote increases delays and reduces bulk throughput. SOP+LSTM occupies a middle ground between these extremes: the tested LSTM-assisted configuration shifts the observed latency-throughput operating point toward latency-sensitive flows at the cost of throughput. For bulk traffic, the Always MEC policy remains stronger in this setting, so SOP+LSTM should not be interpreted as a best-performing policy across all flow types.

4.4. Summary of Results

Taken together, the results show two connected aspects of SOP data handling. At the forwarding stage, SOP scheduling reduces queue buildup and improves completion ratios within the simplified backhaul scheduler suite. Across the four backhaul cases, SOP SRK-EQ reduces the completed-upload median from 20.1 s (baseline) to 11.3 s and increases the completion ratio from 70.9% to 94.3% (five-seed descriptive means; Section 4.1). In the congested method comparison over 20 seeds, SK-EQ, SRK-EQ, and SRK-LRF reach completion ratios of 83.3%, 92.5%, and 86.4%, respectively, compared with 75.2% for ALL-EQ and 46.6% for ALL-LRF. At the allocation stage, the LSTM-assisted configuration shifts the latency-throughput balance toward latency-sensitive flows, with the packet-size adaptation active in that configuration contributing to the difference. Compared with Always MEC and Always Remote, SOP+LSTM is an intermediate policy in this setting rather than a dominant policy for every traffic class. Under the extended 20-seed evaluation of Section 4.2.2 these trends hold with 20-seed 95% confidence intervals (SRK-EQ 92.5 ± 4.6% versus 75.2 ± 12.0% for the all-jobs baseline); a serve-one FCFS/EDF baseline attains higher raw completion (98.0 ± 2.4%) for homogeneous 10 MB jobs, whereas under a heterogeneous 1/10/50 MB mix the equal-allocation shortest-remaining and shortest-k policies deliver among the lowest median and p95 latencies with overlapping completion estimates.

5. Discussion

5.1. Findings and Interpretation

The two SOP layers evaluated in this paper—deadline-constrained backhaul forwarding and predictive radio-aware allocation—address different aspects of the same edge-cloud data management problem. The forwarding-stage experiments show that bandwidth scheduling decisions can dominate completion outcomes when SOS-to-remote capacity is constrained relative to offered load. SRK-EQ (shortest-remaining-k selection with equal bandwidth) outperforms the all-jobs baseline because it serves shorter or shorter-remaining jobs ahead of those unlikely to complete before the dwell deadline, reducing both queue buildup and deadline misses. SK-EQ and SRK-LRF follow the same pattern, while ALL-EQ (equal bandwidth across all jobs) and ALL-LRF (longest-remaining-first across all jobs) leave the queue saturated under the tested arrival rate.

The allocation-stage experiments add a different observation. In the tested configuration, the LSTM-assisted setup shifts the observed latency-throughput operating point: video and sensor delays drop while measured per-flow throughput across all flow classes decreases (a configuration-level effect that includes the ML-mode packet-size adaptation; Section 4.3.2). The Always-MEC policy remains stronger for bulk traffic in the tested NR setting, so the LSTM-assisted configuration should be read as an option for latency-sensitive flow classes rather than a uniformly dominant policy. This separation between forwarding optimization and allocation tuning supports treating SOP as a two-layer data-management framework, where the forwarding scheduler and the radio-aware allocation signal can be developed and evaluated independently.

5.2. Comparison with Prior Work

Direct numerical comparison with related work in Section 2 is difficult because those studies use different mobility models, traffic definitions, optimization objectives, and often do not release directly reusable NS-3 implementations. Backhaul-focused studies [7,8,9,10,11,12,13,14] generally treat capacity provisioning and routing rather than deadline-constrained forwarding at edge proxies. MEC-focused studies [15,16,17,18,19,20,21,22,23] emphasize computation placement and task offloading rather than proxy-side bandwidth scheduling. Agent and DRL approaches [24,25,26,27,28,29,30,31] cover coordination and offloading decisions but rarely combine accepted-upload scheduling with radio-aware allocation in a single architecture. The proposed SOP framework therefore complements rather than replaces existing offloading and caching designs by addressing the proxy-side edge-cloud data management gap.

The closest contemporaneous design is Hmaidi et al. [34], who use LSTM to predict MEC load and drive roadside-unit (RSU)-level load-balancing variants in IoV. SOP differs in two ways. First, the LSTM signal in SOP is derived from the radio-quality score defined in Section 3.3 (with the deployed inputs constrained by trace availability, Section 4.3.1) and used as a proxy-side allocation signal, whereas Hmaidi et al. use LSTM-based MEC load forecasting to steer RSU load-balancing decisions. Second, the proposed architecture places the radio-aware allocation signal and the deadline-constrained proxy scheduler in consecutive data-handling stages—evaluated separately in this paper (Section 4)—rather than tying a load forecast to a migration policy at the RSU. Privacy- and latency-aware allocation [36] applies a related taxonomy to on-board-unit (OBU)/RSU/cloud routing, which is complementary to SOP’s proxy-side bandwidth scheduling.

5.3. Limitations

The LSTM allocation-signal model is trained on available radio traces and uses a weighted radio-score label rather than measured throughput, delay, or completion probability. The current evaluation therefore supports its use as an allocation signal, not as a validated link-quality predictor. Broader training data, trace-level train/validation/test splits, prediction-error metrics, non-LSTM baselines such as EWMA-only or moving average predictors, and cross-validation would be needed to establish generalization.

The macro-average values in Table 5 should be read together with Figure 13 and Figure 14 because UE count changes the offered load.

Because SOT is idealized, this study does not quantify SOT overhead, selection accuracy, load-balancing quality, or hierarchical SOT scalability; those factors must be evaluated before claiming end-to-end control-plane performance.

Energy consumption is not evaluated. Deadline misses are reflected by completion ratio and dropped-job accounting, and the heterogeneous experiment adds a representative per-size completion comparison; we do not report class-dependent deadline-miss distributions, a formal fairness index, or long-job tail-latency metrics; task success rate beyond upload completion is also outside the present scope.

The Section 4.1 robustness suite uses five seeds and reports mean and distribution summaries; the six-policy comparison of Section 4.2 uses 20 seeds, and Section 4.2.2 reports Student’s t-based 95% confidence intervals, paired significance tests for the headline comparisons, a serve-one FCFS/EDF baseline, a k-sensitivity sweep, a 30–120 Mbps capacity sweep, and a heterogeneous 1/10/50 MB experiment with per-size completion that quantifies large-job starvation. The results should therefore be interpreted as controlled simulation evidence rather than statistical generalization across all traffic regimes. Future work should extend these analyses to larger seed counts, additional size distributions and mixed sensor/video/bulk traffic classes, class-dependent deadlines and priority classes, Jain’s-index fairness and long-job tail-latency metrics, a wider delay/loss sweep that differentiates the Section 4.1 cases, and a system-level ablation that replaces the LSTM with an EWMA-only allocation signal under matched packet-size adaptation, isolating the allocation signal; the priority next step is a modest end-to-end experiment coupling the LSTM allocation front-end with the SRK-EQ forwarding stage.

Two caveats follow from these results. First, with homogeneous job sizes a serve-one FCFS/EDF discipline attains higher raw completion than the proposed scheduling policies; the value of SRK-EQ lies in latency and in heterogeneous-workload robustness, not in maximizing completion for identical jobs. Second, the SOP+LSTM configuration shows lower latency together with reduced measured per-flow throughput (Section 4.3.2); because the packet-size adaptation also differs between the configurations, the causal contribution of the LSTM signal is not isolated, and the benefit is a trade-off confined to latency-sensitive, rate-adaptive classes.

The NR allocation evaluation focuses on the tested highway scenario and traffic mix; broader mobility profiles, traffic mixes, and trace coverage would further strengthen external validity. Direct numerical comparison with the offloading and caching methods surveyed in Section 2 is impractical for the reasons given in Section 5.2; therefore, the present evaluation uses controlled internal baselines and reports the main differences from prior work qualitatively in the discussion.

6. Conclusions

In this paper, we studied selected data-management functions of a Smart Offloading Proxy (SOP) for 5G IoV, rather than an end-to-end validation of a complete edge-cloud architecture. We make three contributions. First, we presented an SOP design that integrates with MEC and separates edge-side upload acceptance from remote forwarding, while noting that SOS selection, handover, and SOT scalability are described but not evaluated. Second, we formalized six proxy-side bandwidth-scheduling policies and provided controlled simulation evidence—with 20-seed 95% confidence intervals, a serve-one FCFS/EDF baseline, a k-sensitivity sweep, and a heterogeneous 1/10/50 MB workload—that shortest-remaining-k policies best balance on-time completion and latency among the proposed policies, with a documented large-job fairness trade-off. Third, we characterized an LSTM-smoothed radio-quality allocation signal and showed that, in the tested single-replay NR runs, the LSTM-assisted configuration attains lower video and sensor delay with reduced measured per-flow throughput, i.e., a configuration-level latency-versus-throughput trade-off rather than a validated predictor gain.

For proxy-side forwarding under the tested congestion model, SRK-EQ reaches a 92.5 ± 4.6% completion ratio over 20 seeds versus 75.2 ± 12.0% for the all-jobs baseline, and delivers among the lowest median and p95 latencies under heterogeneous sizes. Under the paired t-test, its median latency does not differ significantly from that of SK-EQ and is significantly lower than that of the serve-one FCFS baseline; the serve-one baseline nevertheless achieves higher completion in the tested homogeneous workload. These results support the forwarding-stage design within the simplified backhaul model and should be extended with broader mobility, radio-access, and end-to-end control-plane validation.

Future research should extend the proposed SOP framework in several directions, including integration with 5G network slicing to provide differentiated services for various vehicular applications, predictive scheduling algorithms that consider vehicle mobility patterns, cooperative data sharing among multiple SOP nodes, and machine-learning-based optimization of bandwidth allocation using traffic patterns. These directions would strengthen SOP as an intelligent edge-cloud data management layer for smart transportation systems and support the growing demands of connected and autonomous vehicles.