Vehicular Cloud Computing (VCC)

• Vehicular Cloud Computing (VCC) is a distributed computing model that extends traditional cloud services to vehicles, RSUs, and smart devices.
• It enables low-latency service delivery through dynamic resource provisioning, including VM migration and task offloading under stringent QoS requirements.
• VCC architectures span vehicle-based, RSU-based, and heterogeneous models, addressing challenges in mobility, energy efficiency, and security.

Vehicular Cloud Computing (VCC) is the seamless extension of traditional cloud-computing utilities—processing, storage, sensing and communication—into a Vehicular ad hoc Network (VANET). It extends the traditional cloud and its utility computing functionalities across Road-Side Units (RSUs), On-Board Units (OBUs) embedded in vehicles, and personal smart devices of drivers and passengers, thereby pooling under-utilized resources that can be offered to vehicles, drivers on the road, travellers, and customers on the internet. Across the literature, VCC appears as vehicular cloud, roadside cloud, central cloud, hybrid fog/V2X architectures, and end-edge-cloud systems, but the recurring objective is low-latency service delivery under mobility, volatile membership, and stringent QoS requirements (Salahuddin et al., 2018, Yu et al., 2013, Maalej et al., 2022).

1. Concept and architectural substrate

A VCC system federates three classes of physical entities. RSUs are fixed infrastructure nodes, fiber/ethernet-backhauled or cellular-connected, that serve as gateways to the Internet or traditional cloud and host compute, storage and sensing resources. OBUs are embedded vehicular nodes with multi-core CPUs, storage, IEEE 802.11p/WAVE radios and vehicle-sensor interfaces that communicate V2V and V2I for safety, efficiency or infotainment services. Personal smart devices form intra-vehicle PANs over Bluetooth or Wi‑Fi Direct and contribute CPU cycles, memory, sensors and cellular or wireless interfaces. These heterogeneous nodes are interconnected by disparate wired and wireless links, including fiber, Ethernet, 802.11p, 3G/4G, Bluetooth, DSRC, Wi‑Fi, LTE, and 5G, each with its QoS characteristics (Salahuddin et al., 2018).

From the end-user viewpoint, VCC offers these resources as pay-as-you-go Software-as-a-Service, just as a data-center cloud offers compute, storage and networking. In tiered formulations, the architecture is commonly expressed as an in-vehicle tier, a vehicular and infrastructure network tier, and a back-end cloud tier. A formal abstraction treats the system as a graph $G=(V,E)$ where $V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$ and $E=\{\text{V2V, V2I, I2Cloud links}\}$, with each node $v\in V$ carrying a resource vector $R_v=\{\text{CPU, Memory, Storage, Bandwidth}\}$ (Maalej et al., 2022).

Some work emphasizes geographically persistent organization rather than only instantaneous connectivity. The Macro-Micro Cloud paradigm introduces micro clouds as “logically fixed” clusters bound to a geo-region, with the macro cloud acting as a peer-to-peer overlay of micro clouds plus individual vehicles. Other work adopts end–edge–cloud cooperation, where vehicles execute final control actions, edge coordinators manage one intersection or locality, and a cloud coordinator aggregates broader state for global coordination. These variants preserve the same core idea: moving and parked vehicles become first-class computing and storage nodes rather than only network endpoints (Tseng et al., 2017, Jiang et al., 2020).

2. Cloud models and service abstractions

Salahuddin et al. classify the evolution of VCC into four broad families: Static OBU Clouds (“parked clouds”), Dynamic OBU Clouds, RSU-Backed Clouds, and Heterogeneous Integration Clouds. A parallel taxonomy groups most architectures into vehicle-based, RSU-based, and central server-based vehicular clouds. The two taxonomies are compatible: the former refines how OBUs, RSUs, and the Internet/cloud data centers are blended, while the latter emphasizes the dominant hosting locus (Salahuddin et al., 2018, Abduljalil, 2023).

Model	Core organization	Characteristic properties
Vehicle-based / Static or Dynamic OBU Cloud	A set of vehicles form an ad hoc cloud; moving or parked vehicles share resources via V2V	Fully decentralized; quick deployment; high churn; limited per-node resources
RSU-based / Roadside Cloud / RSU-Backed Cloud	A cluster of fixed RSUs equipped with computing/storage, interconnected via wired backhaul	Stable hosts; low latency access; easier resource management; coverage gaps
Central Server–based / Central Cloud	Traditional Internet data centers host VMs reached via 3G/4G/5G or backhaul	Virtually unlimited resources; mature cloud management tools; higher end-to-end latency
Heterogeneous Integration Cloud	Full blend of OBUs, RSUs and the Internet/cloud data centers, further augmented by virtualization/SDN/NFV, ICN, or SOA	Combines low-latency edge and high-capacity central cloud

The generic integrated architecture proposed in later work makes the service logic explicit. It comprises a Service Provider Center Manager (SPCM) as global orchestrator of resource discovery, VM placement and migration; a Service Provider (SP) that advertises services and contracts with vehicles to host VMs; a Service Consumer (SC) that requests services; RSUs as fixed hosts and gateways; Physical Vehicles as mobile hosts with hypervisor, CPU/storage/sensors, V2I/V2V interfaces; and Virtual Vehicles (VVs) as guest VMs instantiated on OBUs or RSUs. The SPCM may reside in the central cloud, an RSU, or even a vehicle, while the SC interacts via a REST-style portal to request VVs (Abduljalil, 2023).

The “Virtual Vehicle” is a virtual machine that migrates from one physical vehicle to another and provides the same services as the physical vehicle according to the consumer’s requirements. In the formalization given for this service, a request is represented as $P=(\ell_s,\ell_d,v_{\text{req}},dir_{\text{req}})$, host selection is based on proximity and matching speed and direction, and migration is triggered if the host moves out of the user’s “zone” or no longer matches the requested speed or direction. This service abstraction turns vehicular mobility itself into a managed runtime property of cloud execution rather than merely a source of link disruption (Abduljalil, 2023).

3. Resource management, provisioning, and migration

Compared with data-center clouds, VCC faces two intrinsic challenges: highly dynamic resource demand and stringent QoS requirements. Vehicular speeds and travel patterns induce rapid fluctuations in both the number of participating nodes and the offered workload, while safety applications impose hard latency and packet-delivery guarantees and infotainment or mapping services require soft real-time bounds. A naïve static allocation inevitably under- or over-provisions, while fully dynamic schemes adapt every $\Delta t$ but incur reconfiguration overhead such as VM migrations and data transfer (Salahuddin et al., 2018).

A central response is to formulate provisioning as a Markov Decision Process $\langle \mathcal S,\mathcal A,P,R\rangle$, where states are feasible VCC configurations, actions are re-provisioning decisions such as adding, removing, or migrating VMs, and rewards penalize migration and over-allocation. One reward definition is

$$R(s,s',a)=-\bigl(\mathrm{migrateCost}(s,s')+\beta\cdot \mathrm{extraVMsCost}(s')\bigr).$$

Salahuddin et al. solve the bounded-resource version offline via policy iteration and show that, when demand patterns fluctuate, the MDP policy invests in “extra” VMs ahead of spikes and reduces cumulative VM migration overhead by up to 30% compared to a greedy heuristic, while QoS compliance remains equal or better because provisioning never falls below the SLA-prescribed VM count (Salahuddin et al., 2018).

Resource management has also been modeled as a noncooperative game in roadside cloudlets. In that formulation, guest VMs compete for CPU and storage by placing bids, the cloudlet divides total resources proportionally to bids, and each VM’s payoff trades off valued resource share against a linear price on its own bids. Because the utility is strictly concave in the bid variables, a Nash equilibrium exists; under mild conditions it is unique, and iterative best-response updates converge. In the reported scenario, convergence occurs in approximately 10 rounds (Yu et al., 2013).

Vehicle mobility makes VM continuity a separate problem from initial placement. One solution is a resource reservation scheme that partitions a cloudlet’s resources into common and reserved pools, where only migrating VMs may use the reserved portion. Local arrivals are admitted only from the commons; migrating arrivals can use the full pool. A continuous-time Markov chain over local and migrated VM populations is then used to choose reservation levels that minimize migrant dropping rate subject to a bound on local blocking. In the reported setup, dropping rates without reservation rise to approximately 0.15, while optimized reservation reduces the dropping rate below approximately 0.03, a reduction of more than 80% (Yu et al., 2013).

4. Task offloading, replication, and learning

Task offloading in VCC spans radio-resource allocation, service-vehicle selection, deadline-aware replication, and multi-task embedding. In Vehicular Edge Cloud Computing (VECC), a vehicle $i$ decides whether to execute locally or offload a task $V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$0. Local overhead is modeled as $V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$1, offloading overhead as $V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$2, and the Stochastic Fair Allocation (SFA) algorithm computes the minimum required resource blocks

$V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$3

SFA has $V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$4 complexity. Under 20 MHz, the reported results show 28/30 admitted offloading users, system-wide overhead reduced from 52.42 to 21.67, time-only reduction from 39.53 to 35.39, and energy-only reduction from 67.75 to 13.07 (Li et al., 2019).

In encounter-based VCC, uncertainty of vehicle meetings motivates replication rather than single-assignment offloading. One finite-horizon sampled-time MDP defines the state by replica counts of unfinished tasks and the elapsed deadline horizon. The structural result is the Balanced-Task-Assignment (BETA) policy: at each RSU–vehicle meeting, always replicate the task that currently has the fewest active replicas. Under the homogeneous memory-less meeting assumption, BETA is proved optimal. A tight closed-form upper bound shows that, in the short-deadline regime, the deadline violation probability follows the Rayleigh distribution approximately. The same analysis links VCC performance to traffic flow theory and shows that the optimum vehicle speed to minimize deadline violation probability is larger than the critical vehicle speed that maximizes traffic flow efficiency (Jiang et al., 2017).

Learning-based offloading addresses volatile action sets and unknown service quality. In one formulation, a Task Vehicle learns the delay performance of neighboring Service Vehicles using an Adaptive Volatile UCB algorithm with occurrence-awareness and load-awareness. The lower confidence bound

$V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$5

reduces exploration on large tasks and increases exploration when a new Service Vehicle appears. Simulations in both synthetic and realistic highway scenarios show that the average per-task offloading delay almost matches a genie-aided optimum and significantly outperforms UCB1, VUCB, and random policies (Sun et al., 2018).

Deadline-aware replication has also been framed as a Contextual-Combinatorial Multi-Armed Bandit problem. DATE-V uses context vectors containing side-information such as speeds, positions, available CPU rate, task size and deadline; it is combinatorial because it selects a super-arm of replications up to a budget $V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$6. The expected reward is

$V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$7

Under Hölder continuity, the algorithm achieves a sublinear regret bound. In simulations based on San Francisco Yellow Cab GPS traces, after $V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$8 tasks DATE-V achieves approximately 90% of Oracle and outperforms mLinUCB, repeated UCB, and Random by 25–40% (Chen et al., 2018).

For concurrent multi-task offloading, tasks and vehicular clouds have been modeled as undirected weighted graphs. The resulting objective trades off task completion time against data exchange cost under constraints of limited contact between vehicles and available resources. Exact enumeration is viable only in low-traffic cases. In rush-hour cases, the Connection-Restricted Random Matching algorithm has complexity $V=\{\text{vehicles OBUs, RSUs, cloud servers}\}$9 and converges rapidly to within a few percent of the optimal in small instances, while consistently outperforming degree-preferred and execution-time-preferred greedy baselines (Liwang et al., 2019).

5. Security, simulation, and implementation ecosystems

Security work on VCC commonly assumes an honest-but-curious vehicular cloud for storage, potentially malicious RSUs and vehicles, and external adversaries capable of eavesdropping, replay, or man-in-the-middle attacks. The stated security goals are data confidentiality, data integrity and authenticity, searchability over encrypted data, and resilience to replay, MITM, impersonation, chosen-ciphertext, and session-key-compromise attacks. One protocol stack uses a Registration Authority, a tamper-proof device in the vehicle, a three-phase structure of initialization, registration, and message communication, elliptic-curve Diffie–Hellman session-key establishment, symmetric encryption, MACs, and searchable encryption indices for encrypted data stored in the vehicular cloud (Limbasiya et al., 2019).

In the reported test-bed, authentication and key agreement require approximately 6–10 ms on an OBU, symmetric encryption of a 1 KB record requires approximately 0.3 ms, batch verification for an RSU aggregating 50 vehicles reduces per-vehicle cost from approximately 1.2 ms to approximately 0.05 ms, and search time over 10 000 records at the vehicular cloud is approximately 15 ms. The authors also report formal verification with AVISPA and ProVerif, with no secrecy or authentication property violated even if the adversary controls the network (Limbasiya et al., 2019).

Implementation and evaluation have also advanced through integrated simulators. An ETSI MEC-compliant OMNeT++/Simu5G platform models vehicles as far-edge resource providers, MEC hosts collocated with gNBs, and 5G radio and core elements. The platform extends OMNeT++ and Simu5G with a car module, a VIM module, and an extended Application Mobility Service. Resource-subscription events follow a Poisson process, service times are exponential, and propagation delays are modeled as $E=\{\text{V2V, V2I, I2Cloud links}\}$0. In the reported parking-lot scenario with up to 100 vehicles, resource acquisition time grows from approximately 13 ms at 10 vehicles to approximately 40 ms at 100 vehicles, resource release remains approximately 7 ms regardless of pool size, and application allocation delay remains below 40 ms even under 300 simultaneous requests. The same platform is used to validate scheduling algorithms and migration policies in 24-hour scenarios derived from real parking and WiFi activity traces (Feraudo et al., 2024).

6. Energy, economics, autonomous driving, and research frontiers

A persistent theme in VCC is that local vehicular and edge resources can reduce dependence on distant clouds. In a three-tier vehicular–edge–cloud architecture optimized by mixed-integer linear programming, low processing demands remain local and yield 70–90% power savings versus a cloud-only scheme; for medium and large demands, savings fall to 20–30% once local capacity saturates and cloud use dominates. A related three-layer formulation reports power savings as high as 84% over processing in the conventional cloud, with a real-time heuristic whose total power is within 0–25% of the MILP optimum and typically under 15% for single-demand cases (Behbehani et al., 2019, Behbehani et al., 2021).

The relation between VCC and Edge Computing is a major point of comparison rather than a settled replacement narrative. Simulation studies in urban settings report that VCC can replace EC for moderate workloads and moderate user loads provided that several vehicles are in range, but “Ultra-Low” latency at 16 ms is unattainable on VCC in the studied IEEE 802.11p setting. In a 5G-based formulation, VCC can effectively replace EC for low-latency applications, except in extreme cases when the EC is still required, specifically latency $E=\{\text{V2V, V2I, I2Cloud links}\}$1 ms. Reported cost models show that VCC has zero infrastructural CAPEX for the network operator, and one five-year comparison reports $E=\{\text{V2V, V2I, I2Cloud links}\}$2 USD for ECFirst versus $E=\{\text{V2V, V2I, I2Cloud links}\}$3 USD for VCCFirst in a one-cell scenario. These results directly counter the misconception that VCC and EC are interchangeable under all latency targets: the literature repeatedly preserves a role for dedicated edge when latency constraints are extremely stringent or load is very high (Patanè et al., 2024, Patanè et al., 21 Jul 2025).

Recent management work extends the comparison from cost to sustainability. In a 5G-enabled urban setting with energy-aware task allocation and a game-theoretic revenue-sharing mechanism, average completion time falls from approximately 70 ms toward approximately 30–40 ms as vehicle density increases, low-latency operation below 50 ms is reported, and vehicular offloading can generate monthly net revenue of \$E=\{\text{V2V, V2I, I2Cloud links}\}$41.86 for a single vehicle owner using 2 h/day of offloading. The same study reports five-year Edge-server emissions of 1.35–8.75 ton CO$E=\{\text{V2V, V2I, I2Cloud links}\}$5 and five-year VCC emissions per vehicle of 0.35–3.65 kg CO$E=\{\text{V2V, V2I, I2Cloud links}\}$6, corresponding to more than 99.9% emissions reduction by VCC versus dedicated Edge (Patanè et al., 29 Sep 2025).

VCC is also increasingly coupled to autonomous driving and cooperative control. Survey work describes collaborative sensing, HD live maps, trajectory coordination, and platooning as cloud-supported services built on pooled vehicular, RSU, and back-end resources. In the MiVeCC end–edge–cloud framework for multiple unsignalized intersections, edge and cloud coordination are each formulated as MDPs and solved by DDPG-based reinforcement learning; simulation results show improvement in travel efficiency at multiple intersections by up to 4.59 times without collision compared with existing methods. Open challenges identified across the literature include security and privacy, network slicing and QoS, adaptive migration policies, economic models, scalability, standardized V2X connectivity, mobility-aware resource management, cross-cell continuity, edge AI and federated learning, and post-quantum cryptography for V2X (Maalej et al., 2022, Jiang et al., 2020, Sarkar et al., 2023).