Resource Allocation for Network Slicing in 5G/RSU Integrated Networks with Multi-User and Multi-QoS Services

Abstract

Network slicing in 5G systems enables different Quality of Service (QoS) for heterogeneous Vehicle-to-Everything (V2X) applications, yet efficiently allocating resource blocks from both 5G base stations and roadside units (RSUs) across multiple slices remains challenging. Existing approaches either pre-assign users to slices or rely on population-based metaheuristic algorithms that cannot guarantee deterministic real-time performance within the stringent 20 ms latency requirements of vehicular networks. This study formulates the resource allocation problem as an integer programming model that jointly optimizes slice selection and resource allocation to maximize weighted system transmission rate while satisfying heterogeneous QoS constraints. We develop a constructive heuristic algorithm that employs a hierarchical allocation strategy prioritizing 5G resources before RSU resources, coupled with a backfilling mechanism to exploit the remaining resource block capacity. Numerical experiments across abundant 5G and limited resource scenarios demonstrate the algorithm’s effectiveness. First, comparing against Random baseline validates the optimization model’s value, achieving 21.4–24.9% higher weighted throughput in an abundant 5G scenario and 42.5–51.0% improvement under a limited resource scenario. Second, performance evaluation with 500 users shows the proposed constructive heuristic achieves optimal solutions in abundant 5G resource scenarios and 3.5–5.7% optimality gaps in limited resource scenarios, while maintaining an execution time of under 20 ms, which satisfies real-time requirements and executes faster than Gurobi, Simulated Annealing and Round-Robin. Third, scalability analyses across 400–700 users demonstrate favorable performance scaling, as the optimality gap decreases from 5.3% to 3.4% with execution times consistently below 20 ms. The proposed heuristic achieves the highest service admission count while maintaining near-optimal system weighted transmission rate performance, ranking second only to Gurobi solver. Compared with other baseline algorithms, the proposed heuristic delivers a superior balance between solution quality and computational efficiency, confirming its real-time feasibility for large-scale V2X network deployments.

1. Introduction

The rapid evolution of intelligent transportation systems and the proliferation of connected vehicles have ushered in a new era of V2X communication, fundamentally transforming road safety, traffic efficiency, and mobility services. Modern vehicular networks generate an unprecedented diversity of applications ranging from safety-critical collision avoidance and autonomous driving control to bandwidth-intensive infotainment streaming and massive-scale traffic information collection. Each of these applications imposes distinct and often conflicting QoS requirements, including Ultra-Reliable Low-Latency Communication (URLLC) for safety applications, Enhanced Mobile Broadband (eMBB) for multimedia services, and Massive Machine-Type Communication (mMTC) for sensor data aggregation. Accommodating such heterogeneous service demands within a unified communication infrastructure poses formidable challenges for resource management in next-generation vehicular networks. This complexity necessitates granular QoS provisioning across the protocol stack, particularly at the Physical and MAC layers, to facilitate rigorous service isolation [1,2,3]. The fundamental significance of such hierarchical differentiation lies in its capacity to decouple the inherently contradictory performance objectives of heterogeneous V2X services. In a shared wireless environment, a “one-size-fits-all” approach is insufficient; without targeted differentiation, high-throughput eMBB traffic would inevitably compromise the deterministic low-latency essential for URLLC safety alerts. Consequently, layered QoS mechanisms are not merely an optimization but a safety-critical prerequisite, ensuring that life-saving signaling remains shielded from resource contention while maintaining overall network efficiency.

The emergence of 5G network slicing technology provides a promising architectural paradigm to address this heterogeneity challenge [4,5]. Network slicing enables the creation of multiple virtual networks on shared physical infrastructure, with each slice customized to support specific service characteristics and QoS requirements [6,7]. As illustrated in Figure 1, a network slicing architecture can logically partition resources into three specialized slices: the eMBB slice supporting high-bandwidth services such as in-car video streaming, the mMTC slice handling massive low-rate connections for vehicle sensor data uploading, and the URLLC slice ensuring ultra-low latency and high reliability for autonomous driving control. Each slice operates on the same physical infrastructure layer while maintaining service isolation and providing differentiated QoS guarantees. By orchestrating these dedicated slices through a centralized traffic platform, operators can provide service guarantees tailored to diverse vehicular applications, enabling vehicles with heterogeneous service requirements to access appropriate network resources dynamically.

However, realizing effective network slicing in vehicular environments introduces three critical challenges that existing approaches [3,7] have yet to fully address. First, the interdependency between slice selection and resource allocation remains underexplored. Traditional approaches typically pre-assign services to slices based solely on service categories (e.g., all safety messages to the URLLC slice, all entertainment traffic to the eMBB slice), then perform resource allocation within each slice independently. This separation fails to account for dynamic load imbalances across slices and overlooks opportunities for services with mixed QoS requirements to flexibly access multiple slice types. When traffic patterns fluctuate or certain slices become congested, static assignment strategies cannot redistribute load effectively, leading to resource fragmentation where some slices remain underutilized while others face capacity shortages. Second, the integration of heterogeneous 5G and RSU infrastructure requires coordinated orchestration strategies. In typical urban vehicular networks, communication infrastructure comprises both 5G base stations providing wide-area coverage with higher mobility support and RSUs deployed at intersections offering high-capacity, low-latency communication within limited coverage zones. While existing research has explored resource allocation in either 5G networks or RSU-assisted systems separately, efficient joint orchestration of these heterogeneous resources across multiple network slices, exploiting their complementary coverage and capacity characteristics, remains an open challenge. The dynamic and mobile nature of vehicular scenarios further complicates this orchestration: vehicles move rapidly across coverage areas, service demands fluctuate unpredictably with traffic patterns, and radio propagation characteristics vary significantly between deployment scenarios. Third, meeting stringent real-time constraints demands algorithms with deterministic execution guarantees. The 3rd Generation Partnership Project (3GPP) specifications mandate 20 ms end-to-end latency for safety-critical V2X services [8], imposing strict requirements on resource allocation decision cycles. While reinforcement learning (RL) methods have demonstrated impressive adaptability to dynamic vehicular environments, their training convergence times and decision latencies remain unpredictable, potentially violating real-time requirements during critical safety scenarios. Population-based metaheuristic algorithms similarly lack deterministic runtime bounds, with execution times varying significantly across problem instances. Safety-critical vehicular applications require resource allocation algorithms that guarantee solution delivery within predictable time windows, ensuring consistent performance regardless of network complexity or operational conditions.

Addressing these three challenges, this paper proposes a novel resource allocation framework that jointly optimizes slice selection and resource allocation to maximize weighted system transmission rate in sliced vehicular networks. The framework enables direct user-to-slice access where services are not pre-assigned to slices but instead dynamically matched to appropriate slices during the allocation process based on real-time QoS requirements and current resource availability across all slices. The core contribution lies in a constructive heuristic algorithm that: (1) jointly determines service-to-slice assignments and resource distributions through utility-driven prioritization, (2) coordinates 5G and RSU resource blocks via a hierarchical allocation strategy that prioritizes 5G resources before activating RSU capacity to exploit their complementary characteristics, and (3) guarantees solution delivery within strict real-time bounds (20 ms decision cycles). A two-phase allocation mechanism further enhances performance, where the first phase performs priority-based allocation for initially assigned services, while the second phase implements backfilling to serve previously rejected requests using residual capacity, thereby improving overall system throughput and resource utilization.

The remainder of this paper is organized as follows. Section 2 reviews related work on network slicing and resource allocation for vehicular communications. Section 3 formulates the mathematical optimization model, defining the problem, constraints and objective function. Section 4 presents the constructive heuristic algorithm with a detailed pseudocode. Section 5 presents comprehensive experimental results evaluating algorithm performance under various scenarios and parameter settings. Finally, Section 6 concludes the paper with a summary of contributions and directions for future research.

2. Literature Review

Resource allocation in 5G network slicing for vehicular communications has attracted considerable attention, as modern vehicular networks must efficiently distribute limited resources among heterogeneous users with diverse QoS requirements. The emergence of V2X communication introduces unprecedented service heterogeneity, ranging from safety-critical URLLC for collision avoidance and emergency braking to bandwidth-intensive eMBB for in-vehicle infotainment and High-Definition (HD) map updates, along with mMTC for dense sensor data aggregation and traffic monitoring [4,5]. Network slicing has emerged as a key enabling technology that creates logically isolated virtual networks over shared physical infrastructure, with each slice tailored to specific service characteristics [6]. Research efforts addressing resource allocation in sliced vehicular networks fall broadly into three categories: optimization-based methods that provide formal performance guarantees, learning-based frameworks that adapt to dynamic environments, and hybrid strategies that combine both paradigms.

Optimization-based approaches formulate resource allocation as mathematical programming problems to achieve optimal or near-optimal solutions under specified constraints. Su et al. [7] surveyed resource allocation in 5G network slicing, classifying optimization models into general, economic/game-theoretic, and prediction-based categories to address objectives such as throughput, latency, and fairness. Building on these principles, Chen et al. [3] proposed a service-oriented dynamic resource slicing framework for vehicular networks, integrating joint resource block allocation and power control through Lyapunov optimization. Their JRPSV algorithm adaptively adjusts slice resources between eMBB and URLLC services to maximize long-term system capacity while ensuring queue stability. Lee et al. [9] proposed a dynamic network slicing framework for multitenant heterogeneous cloud radio access networks (H-CRANs) that uses convex optimization to maximize resource utilization while ensuring tenant-specific QoS. The two-level scheme optimizes admission control, user association, and resource allocation, achieving higher throughput, fairness, and QoS than baseline methods. Game-theoretic formulations have also been explored: Cui et al. [10] applied a Stackelberg game model where roadside units act as leaders allocating resources to URLLC and eMBB slices as followers, minimizing Age-of-Information and delay for URLLC traffic while ensuring eMBB throughput requirements, achieving 30% improvement in URLLC freshness and delay performance compared to rigid slicing allocations.

The complexity and rapid variability of vehicular networks have motivated artificial intelligence-driven resource management approaches for adaptive network slicing. RL enables systems to learn slicing policies from experience without explicit global optimization models, discovering resource sharing strategies that outperform fixed or greedy allocations as network conditions evolve. Albonda and Pérez-Romero [2] proposed an RL-based radio access network (RAN) slicing strategy for heterogeneous networks supporting eMBB and V2X services, combining offline Q-learning to discover effective slicing policies with lightweight runtime heuristics for allocation decisions, thereby achieving more efficient spectrum utilization between broadband and vehicular slices compared to static proportional splitting. Subsequent research has extensively applied Deep Reinforcement Learning (DRL) for end-to-end network slicing orchestration. Dong et al. [11] introduced a hierarchical DRL framework to jointly optimize inter-slice and intra-slice resource allocation, where a high-level agent periodically adjusts slice-wise resource partitions (allocating bandwidth or time slots to URLLC, eMBB, and mMTC slices) while lower-level agents handle user scheduling within each slice. By modeling the problem as a two-level Markov Decision Process (MDP), this approach learns to coordinate slicing decisions across different timescales, reducing queueing delays for latency-sensitive traffic while avoiding resource waste. Multi-Agent Reinforcement Learning (MARL) has been explored to reflect the distributed nature of vehicular networks: Cui et al. [12] presented a MARL-based slicing framework where each base station acts as an independent agent using multi-agent deep deterministic policy gradient algorithms to allocate local spectrum and computing resources. Li et al. [13] developed a Deep Q-Network algorithm for multi-slice scenarios that jointly considers radio access and core network capacities to maximize user access rates. Machine learning has also enabled predictive slice provisioning: Abood et al. [14] proposed a Long Short-Term Memory (LSTM)-based time-series prediction framework that forecasts each slice’s future resource demand from historical traffic patterns, enabling proactive resource reservation that improves utilization and maintains lower latency and higher reliability for vehicular services as mobility causes rapid load fluctuations.

Hybrid approaches combining optimization techniques with machine learning methods have emerged to address multifaceted challenges in vehicular network slicing. Khan et al. [15] proposed a clustering-based slicing solution for highway scenarios that groups vehicles dynamically and assigns cluster leaders for Vehicle-to-Vehicle (V2V) relay communication in autonomous driving slices, while RSUs handle infotainment traffic via Vehicle-to-Infrastructure (V2I) links, achieving low latency and high reliability for safety-critical messages through slice-aware resource partitioning. Recent work has explored hierarchical frameworks that decompose resource allocation across multiple decision layers. Qiao et al. [16] developed a two-layer hierarchical learning approach where global inter-slice orchestration determines resource partitioning among slices while local intra-slice scheduling optimizes user-level allocation within each slice, employing proximal policy optimization to adapt to dynamic traffic patterns while satisfying heterogeneous QoS constraints. Cui et al. [17] investigated hierarchical resource orchestration across distributed and centralized network units, coordinating spectrum and computing resource allocation to support multiple service types with differentiated QoS guarantees. Hazarika et al. [18] extended hierarchical slicing to three tiers—first partitioning by 3GPP service class (URLLC/eMBB/mMTC), then by vehicle type, and finally by specific applications—integrating federated deep reinforcement learning to enable distributed learning across network nodes while preserving data privacy.

While these approaches have demonstrated significant progress, several opportunities exist to further enhance network slicing frameworks for vehicular communications. First, jointly optimizing slice selection and resource allocation decisions presents a promising direction beyond predetermined user-to-slice mappings. Rather than statically assigning all safety messages to a URLLC slice and all entertainment traffic to an eMBB slice, dynamic slice selection can better balance load distribution and improve system performance, particularly as vehicles generate mixed traffic with heterogeneous QoS requirements. Second, complementing learning-based methods with deterministic heuristics addresses distinct deployment scenarios and requirements. RL excels in long-term adaptation to evolving traffic patterns and network conditions, yet safety-critical vehicular applications such as cooperative platooning or collision avoidance that demand strict latency bounds (3GPP specifies 20 ms for certain safety applications) require algorithms with predictable real-time performance. Constructive heuristics can serve alongside learning-based approaches by providing deterministic response times without extensive training data or retraining when network conditions change abruptly, offering complementary reliability and stability for real-time vehicular slice control where execution time guarantees are paramount.

To explore these complementary opportunities, this study proposes a constructive heuristic algorithm that jointly optimizes slice selection and resource allocation across heterogeneous 5G base station and roadside unit infrastructure while guaranteeing deterministic execution within strict real-time constraints. The proposed algorithm employs a hierarchical allocation strategy, ensuring solution delivery within the 20 ms decision cycles required for V2X safety applications, while enabling dynamic slice selection to improve load balancing and system performance. This approach is designed to operate in conjunction with learning-based frameworks, providing fast, predictable decision-making for safety-critical scenarios, while learning-based methods can optimize long-term resource utilization and adaptation. The optimization model is presented in the following section.

3. Model Formulation

3.1. Problem Settings and Assumptions

This model addresses resource allocation on the network side of each slice in a V2X communication system. We consider a scenario where each user may request multiple services, with each service having specific QoS requirements. The resource allocation is performed periodically, and within each allocation cycle, the number of available 5G and RSU resource blocks for each slice is assumed to be known.

The key assumptions underlying this model are as follows:

• Each user can simultaneously request multiple services with heterogeneous QoS demands.
• Resource allocation decisions are made at regular intervals (allocation cycles).
• The capacity of 5G and RSU resource blocks for each network slice is determined at the beginning of each cycle and remains constant throughout that cycle.
• Services are assigned to network slices based on QoS compatibility, where a service can only be admitted to a slice if the slice’s QoS characteristics meet or exceed the service’s requirements.
• Resource allocation follows a hierarchical strategy: 5G resource blocks are allocated first, and RSU resource blocks are utilized only when 5G resources are exhausted.

While the above assumptions simplify the problem for mathematical tractability, they are aligned with practical requirements in V2X systems. In particular, our formulation assumes fixed resource blocks and approximately static QoS requirements and service demands within one scheduling cycle. This approximation is justified because the scheduling interval is 20 ms, which is significantly shorter than the typical timescale of mobility-induced channel evolution and demand fluctuations in V2X scenarios. Therefore, within a 20 ms cycle, the demand and QoS requirements can be reasonably treated as quasi-static approximations for resource allocation decisions.

3.2. Mathematical Model

The notation used throughout this paper is summarized in

Table 1. Notation and Definition.

Notation	Definition
Sets
I	Set of users
$J_i$	Set of services for user i
K	Set of network slices
Parameters
$r_k^{5G}$	Available 5G resource blocks for slice k
$r_k^{RSU}$	Available RSU resource blocks for slice k
$r_{ijk}^{req}$	Resource blocks required to meet QoS of service j of user i on slice k
$v_{ijk}^{5G}$	Transmission rate per 5G resource block for service j of user i on slice k
$v_{ijk}^{RSU}$	Transmission rate per RSU resource block for service j of user i on slice k
$w_{ijk}$	Priority weight of service j of user i on slice k
$QO{S}_{ij}$	QoS requirements of service j of user i: $Reliabilit{y}_{ij}$, $Latenc{y}_{ij}$
$QO{S}_k$	QoS characteristics of slice k: $Reliabilit{y}_k$, $Latenc{y}_k$
$a_{ijk}$	Binary indicator: $a_{ijk}=1$ if $(Reliabilit{y}_{ij}⩽Reliabilit{y}_k)\wedge (Latenc{y}_{ij}⩾Latenc{y}_k)$, 0 otherwise
M	Large positive constant (big-M parameter)
Decision Variables
$x_{ijk}^{5G}$	Number of 5G resource blocks allocated to service j of user i on slice k
$x_{ijk}^{RSU}$	Number of RSU resource blocks allocated to service j of user i on slice k
$x_{ijk}$	Total resource blocks allocated to service j of user i on slice k
$y_k$	Binary variable: 1 if slice k uses RSU resource blocks, 0 otherwise
$z_{ijk}$	Binary variable: 1 if service j of user i is served on slice k, 0 otherwise

.

$$\begin{array}{cc}\hfill max& \sum _{k\in K}\sum _{i\in I}\sum _{j\in J_i}{w}_{ijk}\left(v_{ijk}^{5G}{x}_{ijk}^{5G}+v_{ijk}^{RSU}{x}_{ijk}^{RSU}\right)\hfill \end{array}$$

(1)

$$\begin{array}{cccc}\hfill \mathrm{s}.\mathrm{t}.& x_{ijk}=x_{ijk}^{5G}+x_{ijk}^{RSU},\hfill & \hfill & \forall i\in I,\forall j\in J_i,\forall k\in K,\hfill \end{array}$$

(2)

$$\begin{array}{cccc}\hfill & \sum _{i\in I}\sum _{j\in J_i}{x}_{ijk}^{5G}⩽r_k^{5G},\hfill & \hfill & \forall k\in K,\hfill \end{array}$$

(3)

$$\begin{array}{cccc}\hfill & \sum _{i\in I}\sum _{j\in J_i}{x}_{ijk}^{RSU}⩽r_k^{RSU},\hfill & \hfill & \forall k\in K,\hfill \end{array}$$

(4)

$$\begin{array}{cccc}\hfill & \sum _{i\in I}\sum _{j\in J_i}{x}_{ijk}^{RSU}⩽M{y}_k,\hfill & \hfill & \forall k\in K,\hfill \end{array}$$

(5)

$$\begin{array}{cccc}\hfill & \sum _{i\in I}\sum _{j\in J_i}{x}_{ijk}^{5G}⩾r_k^{5G}-M\left(1-y_k\right),\hfill & \hfill & \forall k\in K,\hfill \end{array}$$

(6)

$$\begin{array}{cccc}\hfill & x_{ijk}\le r_{ijk}^{req}{z}_{ijk},\hfill & \hfill & \forall i\in I,\forall j\in J_i,\forall k\in K,\hfill \end{array}$$

(7)

$$\begin{array}{cccc}\hfill & x_{ijk}\ge r_{ijk}^{req}{z}_{ijk},\hfill & \hfill & \forall i\in I,\forall j\in J_i,\forall k\in K,\hfill \end{array}$$

(8)

$$\begin{array}{cccc}\hfill & z_{ijk}⩽a_{ijk},\hfill & \hfill & \forall i\in I,\forall j\in J_i,\forall k\in K,\hfill \end{array}$$

(9)

$$\begin{array}{cccc}\hfill & \sum _{k\in K}{z}_{ijk}⩽1,\hfill & \hfill & \forall i\in I,\forall j\in J_i,\hfill \end{array}$$

(10)

$$\begin{array}{cccc}\hfill & x_{ijk},x_{ijk}^{5G},x_{ijk}^{RSU}\in {\mathbb{Z}}^{+},\hfill & \hfill & \forall i\in I,\forall j\in J_i,\forall k\in K,\hfill \end{array}$$

(11)

$$\begin{array}{cccc}\hfill & y_k\in \{0,1\},\hfill & \hfill & \forall k\in K,\hfill \end{array}$$

(12)

$$\begin{array}{cccc}\hfill & z_{ijk}\in \{0,1\},\hfill & \hfill & \forall i\in I,\forall j\in J_i,\forall k\in K.\hfill \end{array}$$

(13)

To demonstrate the model formulation, we present an illustrative example. Consider a scenario with two users ($I=\{1,2\}$), where user 1 requests an autonomous driving service ($J_1=\left\{1\right\}$) with QoS requirements $Reliabilit{y}_{11}=99.999\%$ and $Latenc{y}_{11}=20$ ms, requiring $r_{11}^{req}=10$ RBs, and user 2 requests a video streaming service ($J_2=\left\{1\right\}$) with $Reliabilit{y}_{21}=99\%$ and $Latenc{y}_{21}=100$ ms, requiring $r_{21}^{req}=20$ RBs. The network provides three slices ($K=\{URLLC,eMBB,mMTC\}$) with characteristics: URLLC ($Reliabilit{y}_{URLLC}=99.999\%$, $Latenc{y}_{URLLC}=10$ ms, $r_{URLLC}^{5G}=100$ RBs, $r_{URLLC}^{RSU}=50$ RBs) and eMBB ($Reliabilit{y}_{eMBB}=99\%$, $Latenc{y}_{eMBB}=50$ ms, $r_{eMBB}^{5G}=150$ RBs, $r_{eMBB}^{RSU}=80$ RBs).

The model first evaluates QoS compatibility: For user 1’s service, $a_{11,URLLC}=1$ since $(99.999\%⩽99.999\%)\wedge (20\mathrm{ms}⩾10\mathrm{ms})$, while $a_{11,eMBB}=0$ because the eMBB slice cannot meet the 20 ms latency requirement. For user 2’s service, both $a_{21,URLLC}=1$ and $a_{21,eMBB}=1$ satisfy QoS compatibility.

Given priority weights $w_{11,URLLC}=10$, $w_{21,eMBB}=5$ and transmission rates $v_{11,URLLC}^{5G}=500$ kbps/RB, $v_{21,eMBB}^{5G}=700$ kbps/RB, the model then determines: (1) slice assignments by solving $z_{11,URLLC}=1$, $z_{21,eMBB}=1$ to maximize weighted throughput under constraint (10), ensuring each service accesses only one slice; (2) resource allocations $x_{11,URLLC}^{5G}=10$ RBs, $x_{21,eMBB}^{5G}=20$ RBs under constraints (7) and (8), meeting exact service demands; and (3) resource prioritation with $x_{11,URLLC}^{RSU}=0$ and $x_{21,eMBB}^{RSU}=0$ following the hierarchical allocation constraints (5) and (6), prioritizing 5G resources. The resulting weighted system throughput is $10\times 500\times 10+5\times 700\times 20=\mathrm{120,000}$ kbps.

3.3. Model Description

The objective function (1) maximizes the weighted system transmission rate (i.e., weighted throughput) across all users, services, and network slices. The priority weights $w_{ijk}$ enable flexible differentiation among service classes and users. To prevent the long-term starvation of low-priority services, our framework relies on the dynamic configurability of these priority weights. Since the resource allocation executes every 20 ms, the central controller (e.g., the One Traffic Platform) can monitor the waiting time or rejection count of services. For temporal fairness, if a low-priority service (e.g., Infotainment) is rejected for multiple consecutive cycles, the platform can dynamically increase its weight in the next cycle. This “human-in-the-loop” or “platform-level” adjustment allows operators to balance the system between strict safety prioritization and long-term fairness, ensuring that even low-priority tasks eventually receive a resource window.

The model incorporates the following constraints:

Resource composition constraint (2): For each service admitted to a slice, the total allocated resource blocks must equal the sum of 5G and RSU resource blocks assigned to that service.

5G capacity constraint (3): The total number of 5G resource blocks allocated across all services within each slice cannot exceed the slice’s available 5G capacity.

RSU capacity constraint (4): Similarly, the total RSU resource blocks allocated within each slice must not exceed the slice’s RSU capacity.

Hierarchical allocation constraints (5) and (6): These constraints enforce the priority allocation strategy where 5G resources are fully utilized before RSU resources are deployed. Constraint (5) ensures RSU resources can only be used (i.e., $y_k=1$) when activated, while constraint (6) ensures that if RSU resources are not used ($y_k=0$), the 5G capacity must be fully allocated.

Service demand satisfaction constraints (7) and (8): When a service is assigned to a slice ($z_{ijk}=1$), the allocated resources must exactly match the service’s required resource blocks $r_{ijk}^{req}$. If the service is not assigned to the slice ($z_{ijk}=0$), no resources are allocated.

QoS matching constraint (9): A service can only be admitted to a slice if the slice’s QoS characteristics (reliability and latency) meet or exceed the service’s requirements, as indicated by $a_{ijk}=1$.

Single slice assignment constraint (10): Each service of each user can be assigned to at most one network slice, preventing service duplication across slices.

Variable domain constraints (11)–(13): These constraints define the feasible domains for all decision variables, where resource allocations are non-negative integers and assignment indicators are binary.

4. Heuristic Algorithm for V2X Resource Allocation

Given the NP-hard nature of the resource allocation problem and the stringent real-time constraints in vehicular networks (20 ms decision cycles), we develop a novel constructive heuristic algorithm tailored to this problem. The algorithm operates in two main phases: (1) a first-phase allocation that determines service-to-slice assignments and performs resource distribution based on resource availability, and (2) a second-phase backfilling mechanism that leverages residual capacity to serve previously unallocated service requests.

4.1. Algorithm Overview

The proposed constructive heuristic algorithm consists of four key components:

• Service-to-Slice Assignment: Determines which network slice each service request should access based on QoS compatibility and potential utility contribution.
• Resource Scenario Detection: Analyzes resource availability within each slice to classify the allocation scenario and select the appropriate distribution strategy.
• First-Phase Resource Allocation: Distributes 5G and RSU resource blocks to admitted services following prioritized strategies tailored to resource availability scenarios.
• Second-Phase Backfilling: Attempts to serve initially rejected requests using residual capacity across all slices.

The algorithm ensures compliance with the constraint that 5G resource blocks must be allocated before RSU resources, exploiting the fact that in most cases, a single resource type suffices to satisfy user demands. This hierarchical allocation strategy maximizes utilization of the preferred 5G infrastructure while maintaining RSU resources as a supplementary capacity buffer.

Algorithm 1 presents the overall structure of the heuristic algorithm. For each scheduling cycle, the algorithm loads valid service requests (those satisfying QoS matching constraints), performs service-to-slice assignment, executes first-phase resource allocation for each slice, and conducts second-phase backfilling for unserved requests.

Algorithm 1 Overall Heuristic Algorithm

1: procedure OverallHeuristicAlgorithm($\mathcal{D}$, $\mathcal{S}$)   2:   Input: $\mathcal{D}$: Service dataset with detailed information about V2X service requests   3:   Input: $\mathcal{S}$: Network slices dataset with capacity information   4:   Output: Allocation results for each scheduling cycle with objective values   5:   $Results\leftarrow \varnothing$   6:   for each scheduling cycle $\tau$ do   7:     $validServices\leftarrow$ LoadValidServices$(\mathcal{D},\tau )$          ▹$a_{ijk}=1$   8:     $slices\leftarrow$LoadSlices$(\mathcal{S},\tau )$   9:     $serviceAssignments\leftarrow$ServicetoSliceAssignment$\left(validServices\right)$ 10:     $allServiceKeys\leftarrow$ extract all user-service combinations from $serviceAssignments$ 11:     $allocatedServices\leftarrow \varnothing$ 12:     $remainingCapacities\leftarrow$ initialize from slice data 13:     for all $s\in slices$ do 14:       $assignedToSlice\leftarrow \{service\in serviceAssignments|service.slice=s.id\}$ 15:       if $assignedToSlice\ne \varnothing$ then 16:         $scenario\leftarrow$DetectResourceScenario$(assignedToSlice,s)$ 17:         $allocations\leftarrow$SliceResourceAllocation(assignedToSlice, s, scenario) 18:         $allocatedServices\leftarrow allocatedServices\cup allocations$ 19:         Update $remainingCapacities$ 20:       end if 21:     end for 22:     $successfullyAllocatedServices\leftarrow$ extract keys from $allocatedServices$ 23:     $unservedServiceKeys\leftarrow allServiceKeys-successfullyAllocatedServices$ 24:     if $unservedServiceKeys\ne \varnothing$ then 25:       $newlyAllocatedServices\leftarrow$ 26:        Second-PhaseBackfilling$(unservedServiceKeys,remainingCapacities)$ 27:       $allocatedServices\leftarrow allocatedServices\cup newlyAllocatedServices$ 28:     end if 29:     $totalObjective\leftarrow {\sum }_{service\in allocatedServices}service.objectiveContribution$ 30:     $Results\leftarrow Results\cup \left\{\right(\tau ,totalObjective,allocatedServices\left)\right\}$ 31:   end for 32:   return $Results$ 33: end procedure

4.2. Service-to-Slice Assignment

The first critical step determines which service requests should be admitted to which network slices. The algorithm processes only combinations where $a_{ijk}=1$, ensuring satisfaction of the QoS matching constraint—services can only access slices whose QoS characteristics meet or exceed their requirements.

Since the hierarchical allocation strategy prioritizes 5G resources before RSU resources, and in most scenarios only one resource type suffices to satisfy service demands, we evaluate each service-slice combination using two complementary perspectives. For each valid $(i,j,k)$ combination, we first compute the absolute throughput contribution under each resource type:

$$Scor{e}_{5G}(i,j,k)=w_{ijk}\times v_{ijk}^{5G}\times r_{ijk}^{req}.$$

(14)

$$Scor{e}_{RSU}(i,j,k)=w_{ijk}\times v_{ijk}^{RSU}\times r_{ijk}^{req}.$$

(15)

These scores represent the weighted throughput contribution if the service is fully satisfied using only 5G or only RSU resources, respectively. We then derive the per-resource-block efficiency by dividing by the required resource blocks:

$$Efficienc{y}_{5G}(i,j,k)={\displaystyle \frac{Scor{e}_{5G}(i,j,k)}{r_{ijk}^{req}}}=w_{ijk}\times v_{ijk}^{5G}.$$

(16)

$$Efficienc{y}_{RSU}(i,j,k)={\displaystyle \frac{Scor{e}_{RSU}(i,j,k)}{r_{ijk}^{req}}}=w_{ijk}\times v_{ijk}^{RSU}.$$

(17)

These efficiency metrics quantify the weighted throughput gain per resource block consumed, enabling comparison of services with different resource demands.

To establish allocation priorities, we construct two aggregate metrics for each service-slice combination:

$$total\_utility=max(Scor{e}_{5G}(i,j,k),Scor{e}_{RSU}(i,j,k)).$$

(18)

$$resource\_efficiency=max(Efficienc{y}_{5G}(i,j,k),Efficienc{y}_{RSU}(i,j,k)).$$

(19)

The $total\_utility$ metric selects the maximum absolute throughput contribution achievable using either resource type, representing the service’s potential value to system performance. The $resource\_efficiency$ metric selects the maximum per-resource-block efficiency, favoring services that deliver high throughput gains relative to their resource consumption.

The algorithm performs a two-level sorting of all valid service-slice combinations: primary sorting by $total\_utility$ in descending order (prioritizing high-value services), with ties broken by $resource\_efficiency$ in descending order (favoring resource-efficient services). This hierarchical sorting balances maximizing absolute system throughput while promoting efficient resource utilization.

To satisfy constraint (10) (${\sum }_{k\in K}{z}_{ijk}⩽1$), the algorithm retains only the highest-scored combination for each unique $(use{r}_i,servic{e}_j)$ pair, eliminating duplicate slice assignments for the same service. This greedy selection yields the initial service-to-slice assignment for the first allocation phase.

Algorithm 2 formalizes this procedure, evaluating all QoS-compatible slices for each service, computing utility metrics, performing two-level sorting, and selecting unique assignments.

Algorithm 2 Service to Slice Assignment

1: procedure ServicetoSliceAssignment($validServices$)   2:   $combinations\leftarrow \varnothing$   3:   for each unique service $(u,i)$ in $validServices$ do   4:     $options\leftarrow$ GetValidSlicesForService($validServices$, u, i)   5:     for each option $o\in options$ do   6:       $r_{req}\leftarrow o.r_{req}$        ▹ Unified resource requirement   7:       $max5GUtility\leftarrow o.weight\times o.v_{5G}\times r_{req}$   8:       $maxRSUUtility\leftarrow o.weight\times o.v_{RSU}\times r_{req}$   9:       $totalUtility\leftarrow max(max5GUtility,maxRSUUtility)$ 10:       $resourceEfficiency\leftarrow totalUtility/r_{req}$ 11:       $combinations\leftarrow combinations\cup$ 12:         $\left\{\right(u,i,o.slice\_id,totalUtility,resourceEfficiency,o\left)\right\}$ 13:     end for 14:   end for 15:   Sort $combinations$ by $(totalUtility,resourceEfficiency)$ in descending order 16:   $assignments\leftarrow \varnothing$ 17:   $assignedServices\leftarrow \varnothing$ 18:   for each $c\in combinations$ do 19:     if $(c.user\_id,c.service\_id)\notin assignedServices$ then 20:       $assignments\leftarrow assignments\cup \left\{c\right\}$ 21:       $assignedServices\leftarrow assignedServices\cup \left\{\right(c.user\_id,c.service\_id\left)\right\}$ 22:     end if 23:   end for 24:   return $assignments$ 25: end procedure

4.3. Resource Scenario Detection and Allocation Strategies

Following service-to-slice assignment, the algorithm examines resource availability within each slice to determine the appropriate allocation strategy. For each slice k, we compute the ratio of available 5G capacity to total demand from assigned services:

$${\rho }_k^{5G}={\displaystyle \frac{r_k^{5G}}{{\sum }_{(i,j)\in {\mathcal{S}}_k}{r}_{ijk}^{req}}},$$

(20)

where ${\mathcal{S}}_k$ denotes the set of services assigned to slice k. Based on this ratio, two distinct resource scenarios are identified:

• Abundant 5G Scenario (${\rho }_k^{5G}\ge 1$): Sufficient 5G resources exist to satisfy all service demands without activating RSU resources.
• Limited 5G/RSU Scenario (${\rho }_k^{5G}<1$): 5G resources are insufficient, necessitating strategic allocation of both 5G and RSU resource blocks.

Algorithm 3 presents the resource scenario detection procedure, which computes the capacity-to-demand ratio and determines the appropriate allocation strategy.

Algorithm 3 Detect Resource Scenario

1: procedure DetectResourceScenario($assignedServices$, $sliceInfo$)   2:   $r_{5G}^{capacity}\leftarrow sliceInfo.r_{5G}$   3:   $r_{RSU}^{capacity}\leftarrow sliceInfo.r_{RSU}$   4:   $totalDemand5G\leftarrow {\sum }_{s\in assignedServices}s.r_{req}$   5:   ${\rho }_{5G}\leftarrow r_{5G}^{capacity}/max(totalDemand5G,1)$   6:   if ${\rho }_{5G}\ge 1$ then   7:     return $ABUNDANT\_5G$   8:   else   9:     return $LIMITED\_5G$ 10:   end if 11: end procedure

Based on the detected scenario, Algorithm 4 dispatches to the appropriate allocation strategy.

Algorithm 4 Slice Resource Allocation

1: procedure SliceResourceAllocation($assignedServices$, $sliceInfo$, $scenario$)   2:   $sliceId\leftarrow sliceInfo.id$   3:   $r_{5G}^{capacity}\leftarrow sliceInfo.r_{5G}$   4:   $r_{RSU}^{capacity}\leftarrow sliceInfo.r_{RSU}$   5:   if $scenario=ABUNDANT\_5G$ then   6:     return Abundant5G($assignedServices$, $r_{5G}^{capacity}$, $r_{RSU}^{capacity}$, $sliceId$)   7:   else   8:     return 5G/RSUStrategy($assignedServices$, $r_{5G}^{capacity}$, $r_{RSU}^{capacity}$, $sliceId$)   9:   end if 10: end procedure

4.3.1. Abundant 5G Allocation Strategy

When 5G resources are abundant, the algorithm employs a simple on-demand allocation strategy. Since the model constraints prioritize 5G resource allocation and no RSU activation is required, each service receives exactly its required number of 5G resource blocks: $x_{ijk}^{5G}=r_{ijk}^{req}$ and $x_{ijk}^{RSU}=0$. This straightforward approach maximizes resource utilization while ensuring service reliability.

Algorithm 5 details the abundant 5G allocation procedure. Services are sorted by their total utility contribution, and resources are allocated on demand until capacity is exhausted.

Algorithm 5 Abundant 5G Resource Allocation

1: procedure Abundant5GResourceAllocation($services$, $r_{5G}^{capacity}$, $r_{RSU}^{capacity}$, $sliceId$)   2:   $x_{5G}\leftarrow \{i:0\mid i\in \{0,1,\dots ,\left|services\right|-1\left\}\right\}$   ▹ 5G allocation per service   3:   $z\leftarrow \{i:0\mid i\in \{0,1,\dots ,\left|services\right|-1\left\}\right\}$       ▹ Service activation   4:   $total5GAllocated\leftarrow 0$   5:   Sort $services$ by $weight\times v_{5G}\times r_{req}$ in descending order   6:   for each service i in sorted $services$ do   7:     $r_{req}\leftarrow services\left[i\right].r_{req}$   8:     if $r_{req}>0$ and $total5GAllocated+r_{req}\le r_{5G}^{capacity}$ then   9:       $x_{5G}\left[i\right]\leftarrow r_{req}$ 10:       $z\left[i\right]\leftarrow 1$ 11:       $total5GAllocated\leftarrow total5GAllocated+r_{req}$ 12:     end if 13:   end for 14:   $y\leftarrow 0$                        ▹ No RSU 15:   $x_{RSU}\leftarrow \{i:0\mid i\in \{0,1,...,\left|services\right|-1\left\}\right\}$ 16:   $allocated\leftarrow \varnothing$ 17:   for each service i in $services$ do 18:     if $z\left[i\right]=1$ then 19:       $contribution\leftarrow services\left[i\right].weight\times$ 20:        $(services\left[i\right].v_{5G}\times x_{5G}\left[i\right]+services\left[i\right].v_{RSU}\times x_{RSU}\left[i\right])$ 21:       $allocation\leftarrow$ allocationresults 22:       $allocated\leftarrow allocated\cup \left\{allocation\right\}$ 23:     end if 24:   end for 25:   return $allocated$ 26: end procedure

4.3.2. Limited 5G/RSU Allocation Strategy

For scenarios where 5G capacity is insufficient, a more sophisticated three-step allocation strategy is employed:

Step 1: 5G Resource Prioritization. The algorithm first computes a 5G utility contribution score for each service to establish allocation priority:

$$Scor{e}_{5G}^{contrib}(i,j,k)=w_{ijk}\times v_{ijk}^{5G}.$$

(21)

Services within the same slice are sorted in descending order by $Scor{e}_{5G}^{contrib}$, with ties broken by ascending resource demand $r_{ijk}^{req}$. This ordering prioritizes services with high weighted transmission rates per resource block. The algorithm then allocates 5G resources following this priority sequence, assigning requested amounts on demand until 5G capacity is exhausted. The last service in the priority queue receives any remaining fractional 5G capacity, ensuring complete utilization of 5G resources.

Step 2: Priority Restructuring for RSU Allocation. After 5G allocation, services fall into two categories: those partially satisfied (received some 5G resources but not the full required amount) and those completely unserved (received no 5G resources). The algorithm restructures priorities for RSU allocation:

• High Priority: Services with partial 5G allocations that still require additional resources to meet their demands. For these services, we calculate the residual demand: $r_{ijk}^{residual}=r_{ijk}^{req}-x_{ijk}^{5G}$.
• Low Priority: Services with no 5G allocation, ranked by their RSU utility score:

  $$Scor{e}_{RSU}^{contrib}(i,j,k)=w_{ijk}\times v_{ijk}^{RSU}.$$

  (22)

Step 3: RSU Resource Distribution. The algorithm first allocates RSU resources to high-priority services (those with partial 5G satisfaction) in order, filling their residual demands. Once all high-priority demands are satisfied or RSU capacity is exhausted, remaining RSU resources are distributed to low-priority services following descending $Scor{e}_{RSU}^{contrib}$ order, with ties broken by ascending demand. This two-tier priority mechanism ensures that services already receiving partial allocations are completed before initiating new service admissions, improving QoS satisfaction rates.

Algorithm 6 implements the complete limited 5G/RSU allocation strategy, incorporating all three steps described above.

Algorithm 6 5G/RSU Strategy for Limited Resources

1: procedure 5G/RSUHStrategy($services$, $r_{5G}^{capacity}$, $r_{RSU}^{capacity}$, $sliceId$)   2:   $x_{5G}\leftarrow \{i:0\mid i\in \{0,1,\dots ,\left|services\right|-1\left\}\right\}$      ▹ 5G allocation per service   3:   $x_{RSU}\leftarrow \{i:0\mid i\in \{0,1,\dots ,\left|services\right|-1\left\}\right\}$     ▹ RSU allocation per service   4:   $z\leftarrow \{i:0\mid i\in \{0,1,\dots ,\left|services\right|-1\left\}\right\}$          ▹ Service activation   5:   $avail5G\leftarrow r_{5G}^{capacity}$   6:   $availRSU\leftarrow r_{RSU}^{capacity}$   7:   $candidates5G\leftarrow \varnothing$   8:   for each service i in $services$ do   9:     if $services\left[i\right].r_{req}>0$ then 10:       $score\leftarrow services\left[i\right].weight\times services\left[i\right].v_{5G}$ 11:       $candidates5G\leftarrow candidates5G\cup \left\{(i,score,services\left[i\right].r_{req})\right\}$ 12:     end if 13:   end for 14:   Sort $candidates5G$ by $score$ descending, then by $request$ ascending 15:   for each candidate $(i,score,request)$ in $candidates5G$ do 16:     if $avail5G\ge request$ then 17:       $allocatedAmount\leftarrow min(avail5G,request)$ 18:       $x_{5G}\left[i\right]\leftarrow allocatedAmount$ 19:       $z\left[i\right]\leftarrow 1$ 20:       $avail5G\leftarrow avail5G-allocatedAmount$ 21:     end if 22:   end for 23:   $candidatesRSU\leftarrow \varnothing$ 24:   for each service i in $services$ do 25:     if $services\left[i\right].r_{req}>0$ and $x_{5G}\left[i\right]>0$ and $x_{5G}\left[i\right]<services\left[i\right].r_{req}$ then 26:       $score\leftarrow services\left[i\right].weight\times services\left[i\right].v_{RSU}$ 27:       $remainingDemand\leftarrow services\left[i\right].r_{req}-x_{5G}\left[i\right]$ 28:       $candidatesRSU\leftarrow candidatesRSU\cup \left\{\right(i,score,remainingDemand,1\left)\right\}$ 29:     end if 30:   end for 31:   for each service i in $services$ do 32:     if $services\left[i\right].r_{req}>0$ and $x_{5G}\left[i\right]=0$ then 33:       $score\leftarrow services\left[i\right].weight\times services\left[i\right].v_{RSU}$ 34:       $candidatesRSU\leftarrow candidatesRSU\cup \left\{(i,score,services\left[i\right].r_{req},2)\right\}$ 35:     end if 36:   end for 37:   Sort $candidatesRSU$ by priority, then by $score$ descending, then by $request$ ascending 38:   for each candidate $(i,score,request,priority)$ in $candidatesRSU$ do 39:     if $availRSU\ge request$ then 40:       $x_{RSU}\left[i\right]\leftarrow request$ 41:       $z\left[i\right]\leftarrow 1$ 42:       $availRSU\leftarrow availRSU-request$ 43:     end if 44:   end for 45:   $y\leftarrow 1$ if ${\sum }_i{x}_{RSU}\left[i\right]>0$ else 0 46:   $allocated\leftarrow \varnothing$ 47:   for each service i in $services$ do 48:     $totalAllocated\leftarrow x_{5G}\left[i\right]+x_{RSU}\left[i\right]$ 49:     if $z\left[i\right]=1$ and $totalAllocated<services\left[i\right].r_{req}$ then 50:       $z\left[i\right]\leftarrow 0$            ▹ Deactivate if not fully satisfied 51:     end if 52:     if$z\left[i\right]=1$then 53:       $contribution\leftarrow services\left[i\right].weight\times$ 54:        $(services\left[i\right].v_{5G}\times x_{5G}\left[i\right]+services\left[i\right].v_{RSU}\times x_{RSU}\left[i\right])$ 55:       $allocation\leftarrow$ allocationresults 56:       $allocated\leftarrow allocated\cup \left\{allocation\right\}$ 57:     end if 58:   end for 59:   return $allocated$ 60: end procedure

4.4. Second-Phase Backfilling Allocation

The greedy nature of the initial service-to-slice assignment may cause some services to be rejected even though alternative slices with residual capacity could accommodate them. To exploit remaining resources and improve system throughput, the algorithm implements a second-phase backfilling mechanism.

This phase considers all unserved services from the first phase and constructs candidate combinations with all feasible slices (those satisfying QoS compatibility constraints). Each candidate combination is evaluated using the previously defined sorting score $max(Scor{e}_{5G},Scor{e}_{RSU})$, and combinations are processed in descending score order. For each candidate:

• Check if the target slice’s total available capacity (sum of the remaining 5G and RSU resources) can satisfy the service’s demand.
• If sufficient capacity exists, allocate resources following the hierarchical strategy: first allocate 5G resources up to availability or demand, then supplement with RSU resources if needed.
• Update the slice’s remaining capacity immediately after allocation.
• If insufficient capacity exists, proceed to the next highest-scored candidate combination.

This backfilling process continues until all unserved services are either allocated or no feasible candidate combinations remain. By revisiting rejected services and considering alternative slice assignments, the second phase significantly improves resource utilization and system performance.

Algorithm 7 formalizes the second-phase backfilling procedure, which evaluates unserved services against all compatible slices and allocates resources hierarchically when sufficient capacity exists.

Algorithm 7 Second-Phase Backfilling Allocation

1: procedure Second-PhaseBackfilling($unservedServiceKeys$, $remainingCapacities$)   2:   $newlyAllocatedServices\leftarrow \varnothing$   3:   $reallocationCandidates\leftarrow \varnothing$   4:   $unservedData\leftarrow$ filter valid data where $(user\_id,service\_id)\in unservedServiceKeys$   5:   for each option o in $unservedData$ do   6:     $r_{req}\leftarrow o.r_{req}$   7:     $max5GUtility\leftarrow o.weight\times o.v_{5G}\times r_{req}$   8:     $maxRSUUtility\leftarrow o.weight\times o.v_{RSU}\times r_{req}$   9:     $totalUtility\leftarrow max(max5GUtility,maxRSUUtility)$ 10:     $resourceEfficiency\leftarrow totalUtility/r_{req}$ 11:     $candidateInfo\leftarrow$ create candidate with service and utility information 12:     $reallocationCandidates\leftarrow reallocationCandidates\cup \left\{candidateInfo\right\}$ 13:   end for 14:   if $reallocationCandidates=\varnothing$ then 15:     return $newlyAllocatedServices$ 16:   end if 17:   Sort $reallocationCandidates$ by $resourceEfficiency$ in descending order 18:   $reallocatedServiceKeys\leftarrow \varnothing$ 19:   for each candidate c in $reallocationCandidates$ do 20:     $serviceKey\leftarrow (c.user\_id,c.service\_id)$ 21:     if $serviceKey\in reallocatedServiceKeys$ then 22:       continue 23:     end if 24:     $sliceId\leftarrow c.slice\_id$ 25:     $r_{req}\leftarrow c.r_{req}$ 26:     $sliceCap\leftarrow remainingCapacities\left[sliceId\right]$ 27:     $x_{5G}\leftarrow 0,x_{RSU}\leftarrow 0$ 28:     if $sliceCap.r_{5G}+sliceCap.r_{RSU}\ge r_{req}$ then 29:       if $sliceCap.r_{5G}\ge r_{req}$ then 30:         $x_{5G}\leftarrow r_{req}$ 31:       else if $sliceCap.r_{5G}>0$ then 32:         $x_{5G}\leftarrow sliceCap.r_{5G}$ 33:         $x_{RSU}\leftarrow r_{req}-sliceCap.r_{5G}$ 34:       else 35:         $x_{RSU}\leftarrow r_{req}$ 36:       end if 37:     else 38:       continue            ▹ Cannot satisfy full request 39:     end if 40:     $contribution\leftarrow c.weight\times (c.v_{5G}\times x_{5G}+c.v_{RSU}\times x_{RSU})$ 41:     $allocationInfo\leftarrow$ create allocation record with assignment details 42:     $newlyAllocatedServices\leftarrow newlyAllocatedServices\cup \left\{allocationInfo\right\}$ 43:     $reallocatedServiceKeys\leftarrow reallocatedServiceKeys\cup \left\{serviceKey\right\}$ 44:     $remainingCapacities\left[sliceId\right].r_{5G}\leftarrow remainingCapacities\left[sliceId\right].r_{5G}-x_{5G}$ 45:     $remainingCapacities\left[sliceId\right].r_{RSU}\leftarrow remainingCapacities\left[sliceId\right].r_{RSU}-x_{RSU}$ 46:   end for 47:   return $newlyAllocatedServices$ 48: end procedure

4.5. Complexity Analysis

To evaluate the scalability of the proposed constructive heuristic, we analyze its computational and memory complexity. Let $\left|I\right|$ denote the number of users, $\left|J\right|$ the maximum number of services per user, and $\left|K\right|$ the number of network slices.

4.5.1. Computational Complexity

The computational complexity of each algorithm component is analyzed as follows:

• Service-to-Slice Assignment (Algorithm 2): The algorithm evaluates all valid $(i,j,k)$ combinations satisfying the QoS matching constraint in $O\left(\right|I|·|J|·|K\left|\right)$ time. Subsequently, sorting these combinations by utility and efficiency metrics requires $O\left(\right|I|·|J|·|K|log(\left|I\right|·\left|J\right|·\left|K\right|\left)\right)$ operations.
• First-Phase Allocation (Algorithms 5 and 6): For each slice k, the algorithm sorts the assigned services by their utility scores, requiring $O(n_{k}log{n}_k)$ time, where $n_k$ denotes the number of services assigned to slice k. Summing over all slices yields a total complexity of $O\left(\right|I|·|J|log(\left|I\right|·\left|J\right|\left)\right)$.
• Second-Phase Backfilling (Algorithm 7): In the worst case, the algorithm evaluates all unserved services against all compatible slices, constructing and sorting $O\left(\right|I|·|J|·|K\left|\right)$ candidate combinations, resulting in a complexity of $O\left(\right|I|·|J|·|K|log(\left|I\right|·\left|J\right|·\left|K\right|\left)\right)$.

The overall computational complexity is dominated by the sorting operations, yielding $O\left(\right|I|·|J|·|K|log(\left|I\right|·\left|J\right|·\left|K\right|\left)\right)$. This polynomial complexity ensures efficient scalability as the number of users and slices increases, making the algorithm suitable for real-time vehicular network resource allocation.

4.5.2. Memory Complexity

The algorithm maintains data structures for service requests, slice capacities, candidate combinations, and allocation results. The primary memory consumption arises from storing the candidate service-slice combinations and the final allocation decisions, which scales as $O\left(\right|I|·|J|·|K\left|\right)$. For typical V2X deployment scenarios (for instance, 700 concurrent users, each requesting up to 3 services across 5 network slices), the memory footprint is approximately 1–2 MB, ensuring practical feasibility for deployment on resource-constrained vehicular platforms.

5. Numerical Experiments

This section evaluates the proposed constructive heuristic algorithm through comprehensive experiments designed to assess three critical performance dimensions: solution quality, computational efficiency, and scalability. The experimental framework encompasses two resource availability scenarios (abundant 5G and limited 5G requiring coordinated 5G-RSU allocation), four comparative baseline methods (Gurobi solver, Round-Robin, Random allocation, and Simulated Annealing), and realistic V2X workloads with nine heterogeneous service types distributed across five network slices serving varying user populations. The evaluation begins with a comparative analysis between Gurobi optimal solutions and Random baseline to quantify the fundamental value of intelligent resource allocation, followed by comprehensive baseline performance comparisons and scalability analysis across varying user densities. These experiments aim to validate the algorithm’s capability to deliver near-optimal resource allocation decisions within strict real-time constraints mandated by safety-critical vehicular applications, while demonstrating robust performance across diverse operational conditions.

5.1. Data Generation Methodology

To ensure realistic experimental evaluation, we employ a systematic data generation framework that synthesizes network slice characteristics, user service demands, and resource transmission rates based on 3GPP technical specifications [8] and V2X application requirements.

5.1.1. Network Slice Configuration

The experimental framework instantiates five heterogeneous network slices spanning the complete spectrum of V2X QoS requirements, as detailed in

Table 2. Network slice QoS specifications and resource characteristics.

Slice Name	Reliability	Latency (ms)
URLLC_1	0.99999	1
URLLC_2	0.9999	10
eMBB_1	0.999	20
eMBB_2	0.99	50
mMTC	0.95	100

. URLLC_1 represents the most stringent slice with ultra-high reliability of 0.99999 and extremely low latency of 1ms. URLLC_2 provides slightly relaxed but still critical performance with 0.9999 reliability and 10 ms latency. eMBB_1 delivers high-throughput connectivity with 0.999 reliability and 20 ms latency. eMBB_2 offers moderate performance with 0.99 reliability and 50 ms latency. Finally, mMTC supports massive connectivity with 0.95 reliability and 100 ms latency.

Each slice exhibits heterogeneous transmission rate characteristics for 5G base station and RSU resource blocks. As shown in

Table 3. Transmission rate ranges per resource block across network slices.

Slice Name	5G Rate (kbps)	RSU Rate (kbps)
URLLC_1	(300, 600)	(150, 350)
URLLC_2	(300, 600)	(150, 350)
eMBB_1	(500, 900)	(250, 500)
eMBB_2	(500, 900)	(250, 500)
mMTC	(200, 400)	(100, 250)

, URLLC_1 and URLLC_2 provide transmission rates uniformly sampled from 300 to 600 kbps for 5G resources and 150 to 350 kbps for RSU resources per block. eMBB_1 and eMBB_2 support higher rates from 500 to 900 kbps for 5G blocks and 250 to 500 kbps for RSU blocks. The mMTC slice operates at reduced rates from 200 to 400 kbps for 5G resources and 100 to 250 kbps for RSU resources.

5.1.2. User Service Demand Generation

The experimental framework simulates 500 concurrent vehicular users, each requesting one to three heterogeneous V2X services. Service count distribution follows a realistic traffic pattern: 60% of users request a single service, 30% request two services, and 10% request three services, modeling varying application complexity across vehicle types such as basic sedans versus autonomous vehicles with multiple active safety systems.

We define nine distinct V2X service types with diverse QoS requirements, as detailed in

Table 4. V2X service types with QoS requirements and resource specifications.

Service	Reliability	Latency (ms)	Priority Range	Demand Range
EmergencyBrake	0.9999	5	(8, 10)	(1, 3)
CollisionAvoidance	0.999	20	(6, 9)	(2, 5)
PlatooningControl	0.999	25	(5, 8)	(3, 8)
SensorSharing	0.99	50	(4, 7)	(5, 12)
HDMapUpdate	0.99	100	(2, 5)	(10, 25)
Infotainment	0.95	200	(1, 3)	(8, 20)
TrafficSignalControl	0.999	15	(7, 9)	(1, 4)
WeatherAlert	0.97	150	(3, 6)	(2, 6)
RemoteDiagnostics	0.96	180	(2, 5)	(4, 10)

. Each service type is characterized by specific reliability and latency constraints, priority weight ranges, and resource block demand ranges that govern slice compatibility and resource allocation decisions. EmergencyBrake represents the most stringent service with ultra-high reliability of 0.9999 and 5 ms latency, priority weights ranging from 8 to 10, and resource demands between 1 and 3 blocks, making it compatible only with the highest-performance URLLC slices. CollisionAvoidance and TrafficSignalControl provide critical safety functions with 0.999 reliability at 20 ms and 15 ms latency, respectively, using priority weights from 6 to 9 and 7 to 9, with moderate resource demands. PlatooningControl maintains similar reliability requirements at 25 ms latency with priority weights from 5 to 8 and demands from 3 to 8 blocks for coordinated vehicle movement. SensorSharing and HDMapUpdate operate at 0.99 reliability with 50 ms and 100 ms latencies, using priority weights from 4 to 7 and 2 to 5, and resource demands from 5 to 12 and 10 to 25 blocks, respectively, reflecting bandwidth-intensive data exchange requirements. WeatherAlert and RemoteDiagnostics provide informational services with relaxed reliability of 0.97 and 0.96 at 150 ms and 180 ms latencies, priority weights from 3 to 6 and 2 to 5, and moderate resource demands. Infotainment represents the least critical service with 0.95 reliability at 200 ms latency, the lowest priority weights from 1 to 3, and demands from 8 to 20 blocks for entertainment content delivery.

Each user randomly selects services with equal selection probability across all nine service types, ensuring unbiased workload distribution. For each selected service, the system randomly samples specific reliability and latency requirements within tolerance bounds (e.g., ±2% for reliability, ±10% for latency) to introduce realistic QoS variability while maintaining service type characteristics. Priority weights and resource block demands are uniformly sampled from their respective ranges. This perturbation mechanism models the heterogeneity of real-world vehicular environments where identical service types exhibit slight variations due to vehicle mobility, channel conditions, and application configurations. Critically, each user’s service requirements remain fixed across all network slices and do not change between scheduling cycles, ensuring consistent QoS contract enforcement regardless of the assigned slice. This design reflects practical network slicing principles where service level agreements (SLAs) are established per user rather than per slice.

5.1.3. Resource Capacity Configuration

The two experimental scenarios employ distinct resource capacity configurations to evaluate algorithm behavior under varying infrastructure conditions:

Abundant 5G Scenario: Base station capacity is set sufficiently high to accommodate all service demands using only 5G resources, eliminating the need for RSU activation. This models urban areas with dense macro-cell deployments where infrastructure investment prioritizes cellular coverage. RSU capacity remains available but unused, serving as backup infrastructure.

Table 5. Resource configuration across scheduling cycles for abundant 5G scenario.

TTI	Seed	Users	Services	Demand	Cap_5G	Cap_RSU	Cap/Demand
0	0	500	3765	20,589	50,000	500	2.45
1	10	500	3810	21,989	50,000	500	2.30
2	20	500	3660	19,851	50,000	500	2.54
3	30	500	3700	20,994	50,000	500	2.41
4	40	500	3685	20,420	50,000	500	2.47
5	50	500	3710	20,064	50,000	500	2.52
6	60	500	3695	20,854	50,000	500	2.42
7	70	500	3770	22,265	50,000	500	2.27
8	80	500	3765	22,096	50,000	500	2.29
9	90	500	3795	21,654	50,000	500	2.33
Avg	-	500	3716	21,078	50,000	500	2.40

presents the detailed resource configuration across ten scheduling cycles, i.e., Transmission Time Intervals (TTIs) 0–9 for the abundant 5G scenario. Each cycle uses a different random seed (0, 10, 20, …, 90) to generate service demand patterns, with 500 concurrent users requesting 3660–3810 services per cycle. Total service demand ranges from 19,851 to 22,265 resource blocks, while available 5G capacity is fixed at 50,000 resource blocks per cycle across all five network slices (10,000 blocks per slice). RSU capacity is limited to 500 resource blocks (100 blocks per slice) to model backup infrastructure. The resulting capacity-to-demand ratios range from 2.27 to 2.54, ensuring that 5G resources alone can satisfy all service requests without RSU activation.

Limited 5G Scenario: Base station capacity is intentionally constrained to approximately 4.5–5.0% of total service demand, necessitating coordinated 5G-RSU resource management. This reflects severely capacity-constrained highway environments where roadside units augment sparse cellular coverage.

Table 6. Resource configuration across scheduling cycles for limited 5G scenario.

TTI	Seed	Users	Services	Demand	Cap_5G	Cap_RSU	Cap/Demand
0	0	500	3765	20,589	500	500	0.049
1	10	500	3810	21,989	500	500	0.045
2	20	500	3660	19,851	500	500	0.050
3	30	500	3700	20,994	500	500	0.048
4	40	500	3685	20,420	500	500	0.049
5	50	500	3710	20,064	500	500	0.050
6	60	500	3695	20,854	500	500	0.048
7	70	500	3770	22,265	500	500	0.045
8	80	500	3765	22,096	500	500	0.045
9	90	500	3795	21,654	500	500	0.046
Avg	-	500	3716	21,078	500	500	0.048

presents the detailed resource configuration across ten scheduling cycles (TTIs 0–9) for the limited 5G scenario. Each cycle uses a different random seed (0, 10, 20, …, 90) to generate service demand patterns, with 500 concurrent users requesting 3660–3810 services per cycle. Total service demand ranges from 19,851 to 22,265 resource blocks, while available 5G capacity is severely limited to 500 resource blocks per cycle across all five network slices (100 blocks per slice). RSU capacity provides an additional 500 resource blocks (100 blocks per slice) as supplementary infrastructure. The resulting capacity-to-demand ratios range from 0.045 to 0.050 (4.5–5.0%), creating a highly resource-limited environment that requires strategic resource allocation to maximize system performance.

5.2. Comparative Performance Analysis: Gurobi vs. Random Baseline

To establish the fundamental value of our optimization model, we compare the Gurobi optimal solution with a random allocation baseline across both resource scenarios as shown in Figure 2 and Figure 3.

The Random baseline serves as a fundamental performance benchmark representing allocation decisions made without optimization. This baseline randomly shuffles the sequence of service requests and processes them in arbitrary order. For each service, the algorithm randomly selects a QoS-compatible network slice from those with sufficient remaining resource block capacity. Resource allocation within the selected slice follows the same hierarchical 5G-priority strategy: first exhausting available 5G resource blocks before utilizing RSU resource blocks.

In the abundant 5G scenario, Gurobi achieves objective values of approximately $1.6\times {10}^7$ to $1.7\times {10}^7$, while the Random baseline attains $1.2\times {10}^7$ to $1.3\times {10}^7$. From Figure 2, we can see a 21.4% to 24.9% performance gap between Gurobi optimal and Random baseline in each scheduling cycle.

Under limited 5G scenario, Gurobi achieves objective values of approximately $3.25\times {10}^6$ to $3.5\times {10}^6$, while the Random baseline attains an approximately $1.75\times {10}^6$ to $2\times {10}^6$ objective value. From Figure 3, there is a 42.5% to 51.0% performance gap between Gurobi optimal and Random baseline in each scheduling cycle.

These results validate the value of our optimization model as it can increase weighted system throughput compared to arbitrary allocation.

5.3. Algorithm Performance Evaluation and Comparison

This subsection compares algorithm performance under a fixed population of 500 users across both resource scenarios, focusing on solution quality, computational efficiency, and service admission characteristics.

5.3.1. Solution Quality and Computational Time

Figure 4, Figure 5, Figure 6 and Figure 7 present a comprehensive comparison of optimality gaps and computational times across all evaluated algorithms. In the abundant 5G scenario (Figure 4 and Figure 5), Figure 4 shows that both the proposed constructive heuristic and Simulated Annealing achieve optimal solutions across all ten scheduling cycles (TTI 0–9), matching Gurobi’s performance. In contrast, Round-Robin exhibits 22.9–25.2% optimality gaps.

Figure 5 analyzes computational time performance across all evaluated algorithms. The proposed constructive heuristic consistently executes within 12–18 ms across all scheduling cycles, safely meeting the 3GPP-mandated 20 ms real-time requirement for vehicular networks. Gurobi requires 258–337 ms per cycle, while Simulated Annealing demands 5380–5964 ms. Round-Robin executes within 250–318 ms and exhibits 22.9–25.2% optimality gaps, demonstrating that neither computational efficiency nor solution quality can match the proposed constructive heuristic.

In the limited 5G scenario (Figure 6 and Figure 7), Figure 6 shows the proposed constructive heuristic maintains optimality gaps between 3.5% and 5.7% across all scheduling cycles. Simulated Annealing maintains gaps ranging from 10.1% to 12.3%, while Round-Robin’s performance deteriorates dramatically, with gaps ranging from 48.7% to 56.5%.

Figure 7 shows the proposed constructive heuristic executes within 13–17 ms, Gurobi requires 365–519 ms, Simulated Annealing demands 6250–6774 ms, and Round-Robin takes 237–286 ms.

5.3.2. Service Admission Success Rates

Figure 8 and Figure 9 analyze service admission success rates. In the abundant 5G scenario (Figure 8), all algorithms achieve nearly 100% admission rates, as available capacity substantially exceeds demand.

Figure 9 reveals the proposed constructive heuristic’s superiority under limited resources, achieving the highest admission rates of 31–35%, exceeding even Gurobi’s optimal solution. Simulated Annealing achieves 30–34% admission rates, while Round-Robin manages only 15–19%, demonstrating roughly half the performance of the proposed constructive heuristic.

5.4. Scalability Analysis

This subsection examines algorithm scalability as user density increases from 400 to 700 concurrent users under the limited 5G scenario. This stress-test configuration evaluates whether algorithms maintain performance characteristics as network load intensifies, analyzing computational time, solution quality, service admission, and objective values.

5.4.1. Computational Time and Solution Quality Scalability

Figure 10 presents computational time evolution across user densities on a logarithmic scale. As user count increases from 400 to 700, all algorithms exhibit longer execution times. The proposed constructive heuristic maintains execution times between 13 ms and 18 ms, remaining below the 20 ms real-time threshold. Gurobi’s execution time grows from 324 ms to 476 ms, Simulated Annealing ranges from 4925 ms to 8079 ms, and Round-Robin ranges from 184 ms to 312 ms.

Figure 11 analyzes solution quality evolution across user densities. As user count increases from 400 to 700, Round-Robin’s optimality gaps increase from 50.9% to 54.3%. Simulated Annealing maintains relatively stable gaps between 10.9% and 11.7%. The proposed constructive heuristic shows decreasing gaps from 5.3% to 3.4%, remaining within 5.5% across all densities.

5.4.2. Service Admission and Objective Value Scalability

Figure 12 shows allocated services as user density increases from 400 to 700. The proposed constructive heuristic allocates 2385 services at 400 users, growing to 2622 services at 700 users, which is approximately a 10% increase. The heuristic tracks Gurobi’s allocation, which ranges from 2355 to 2584 services, with both showing saturation as the system reaches resource limits. Simulated Annealing allocates between 2285 and 2484 services. Round-Robin allocates fewer services, ranging from 1280 to 1351, about half the heuristic’s performance, wasting significant resource capacity.

Figure 13 presents objective value evolution across 400–700 users. The proposed heuristic grows from $3.13\times {10}^7$ to $3.40\times {10}^7$, Gurobi from $3.31\times {10}^7$ to $3.52\times {10}^7$, Simulated Annealing from $2.92\times {10}^7$ to $3.12\times {10}^7$, while Round-Robin remains nearly flat at $1.59\times {10}^7$–$1.61\times {10}^7$.

The scalability analysis demonstrates three key findings: (1) Computational efficiency: the proposed heuristic maintains 13–18 ms execution time across all user densities, enabling real-time deployment; (2) Solution quality: it achieves 3.4–5.3% optimality gaps under limited resources, outperforming baseline heuristics; (3) Performance across user densities: the proposed heuristic achieves the highest service admission count, while Gurobi attains the maximum system transmission rate throughput, with the heuristic ranking second and both significantly outperforming other baseline algorithms.

6. Conclusions and Future Work

This study addresses the challenge of real-time and efficient resource allocation for multi-slice V2X networks under heterogeneous QoS requirements. By formulating a joint slice selection and resource allocation model as an integer programming problem, the proposed framework captures both the differentiated service demands of vehicular users and the hierarchical nature of 5G and RSU resources. To achieve real-time feasibility, a constructive heuristic algorithm is developed, featuring a hierarchical allocation strategy that prioritizes 5G resources, followed by RSU resource backfilling. This design enables efficient utilization of heterogeneous network resources while ensuring latency constraints are satisfied within the stringent 20 ms limit required for vehicular communication.

Comprehensive numerical experiments validate the effectiveness and practicality of the proposed approach. In both abundant and limited 5G resource scenarios, the heuristic achieves near-optimal performance, outperforming baseline methods such as Random, Simulated Annealing, and Round-Robin in terms of weighted system throughput and service admission rate. The algorithm consistently maintains execution times under 20 ms, confirming its suitability for delay-sensitive V2X applications. Moreover, scalability analysis demonstrates that the performance gap between the heuristic and optimal Gurobi solutions narrows as the number of users increases, further highlighting the method’s robustness and adaptability to large-scale vehicular networks.

Despite the promising results, this work is currently limited to single-cell scenarios with finite traffic loads and slice sets. Future research will address these limitations and expand the framework in several directions: (i) extending the heuristic to multi-cell environments to handle inter-cell interference and coordinated resource orchestration; (ii) evaluating performance under significantly higher traffic loads and larger slice sets, including a more exhaustive analysis of memory and computational overheads; (iii) incorporating predictive traffic and mobility intelligence for proactive capacity reservation; (iv) co-optimizing radio, edge-compute, and network function resources for end-to-end service chains; and (v) embedding machine learning techniques, such as RL, to enhance decision-making in dynamic vehicular environments.