PaperlayerView exact revision on arXiv

Source-linked AI summary

Reusing Spare Vehicle Computing Capacity: Is It Viable, Profitable and Sustainable?

Rosario Patanè, Nadjib Achir, Andrea Araldo, Lila Boukhatem

arXiv:2609.29731v1cs.DC

TL;DR

The paper asks whether reusing vehicles’ spare computing capacity can be viable, profitable, and sustainable, addressing a lack of quantitative evidence. It combines deadline-aware allocation with ex-post incentive design and evaluates the approach through urban-mobility simulation and life-cycle emissions analysis. Vehicles absorb most offloaded traffic, participation can yield monthly driving range, and the reported comparison finds lower emissions than edge computing.

  • Problem

    The practical viability, profitability, and emissions of sharing spare vehicular computing capacity remain unclear.

    Source: §I · p. 1

  • Method

    The framework combines deadline-aware task allocation, robust vehicle admission, and ex-post coalitional revenue sharing based on realized outcomes.

    Source: §I · p. 1, A. Robust Admission · p. 6, A. Robust Coalitional Game · p. 8

  • Results

    Vehicles absorb most offloaded traffic within tens of milliseconds, participation yields up to 157 km of monthly driving range per vehicle, and replacing an edge server saves up to 8.5 t CO2 over its life cycle.

    Source: §X · p. 13

  • Takeaways & Limitations

    The reported results support reusing vehicle capacity as an offloading resource while preserving vehicle-owner incentives and reducing emissions relative to edge infrastructure.

    Source: §X · p. 13

Abstract

from arXiv · show

Vehicular Cloud Computing (VCC) exploits computing hardware already embedded in vehicles for purposes unrelated to offloading and puts its idle cycles to work executing end-users' offloaded tasks, avoiding the deployment of new computation infrastructure. Despite its conceptual appeal, adoption is hindered by the lack of quantitative evidence that sharing spare vehicular capacity is viable, profitable and sustainable. A management scheme for task offloading sustains deadline-constrained execution by decoupling deadline-aware allocation from ex-post incentive design, making the approach viable. A robust coalitional game and a vehicle-selection mechanism keep the network operator and the vehicle owners profitable even under unfavorable outcomes of the random environment, e.g.,mobility, radio conditions, or vehicles overstating their spare capacity. A simulation campaign on realistic urban mobility, using Simulation of Urban MObility (SUMO) traces of Rome,together with a CO2 life-cycle assessment against edge computing infrastructure, whose footprint, is attributed pro rata to the share of its capacity devoted to offloading shows the approach to be sustainable. Vehicles absorb most of the offloaded traffic within tens of milliseconds; participation yields up to 157 km of monthly driving range per vehicle; and life-cycle emissions drop by over 99% when using VCC compared to that edge infrastructure.

I. INTRODUCTION

The paper asks whether sharing vehicles’ spare computing capacity can be viable, profitable, and sustainable, and positions its framework as a way to evaluate those questions jointly. It combines deadline-aware allocation with separate incentive design and addresses real-time constraints and declared-capacity uncertainty.

I. INTRODUCTION

  • The paper frames VCC’s practical viability, profitability, and emissions as open questions despite the promise of reusing spare vehicle capacity without new hardware.It defines spare capacity as the fraction of a vehicle’s onboard computing capacity offered for offloading.Source: §I · p. 1

A. Task Allocation in Vehicular Systems

  • The framework integrates mobility, heterogeneous onboard resources, and energy constraints into a cooperative optimization strategy for vehicular task allocation.Earlier work explored energy-performance tradeoffs, location- and delay-aware allocation, and mobility-aware task distribution.Source: A. Task Allocation in Vehicular Systems · p. 2

B. Cooperative Offloading under Real-Time Constraints

  • Lightweight, bounded-complexity allocation is designed for millisecond-scale decision windows while ensuring deadline compliance.The cited learning-based schemes improve average latency but do not guarantee deadline satisfaction or computational boundedness [13].Source: B. Cooperative Offloading under… · p. 2

C. Game-Theoretic Cooperation

  • The framework separates real-time allocation from ex-post cooperative payoff evaluation to avoid in-loop coalition valuation.Prior game-theoretic approaches often rely on costly online coalition evaluation and lack integrated delay, energy, and profitability models.Source: C. Game-Theoretic Cooperation · p. 2

D. Robustness to Declared Capacity

  • A Wasserstein-based admission rule filters executors whose declared capacity may exceed their realized capacity before allocation.Earlier approaches take declared beacon capacity at face value, potentially assigning tasks that an over-reporting executor cannot complete [18, 19].Source: D. Robustness to Declared Capacity · p. 2

E. Positioning of This Work

The paper positions its work as a cooperative offloading framework that jointly models latency, energy, and monetary cost. A centralized controller coordinates vehicular and cloud resources, allocating tasks against estimated delays that include executor queueing.

E. Positioning of This Work

  • The framework jointly accounts for latency, energy, and monetary cost while modeling the Network Operator, Vehicle Owners, and Cloud Computing as distinct stakeholders.Its evaluation uses reproducible simulations grounded in urban vehicular mobility and energy models.Source: E. Positioning of This Work · p. 2

III. ARCHITECTURE

  • The centralized 5G architecture coordinates end-users, a gNodeB-linked Controller, vehicles, and a cloud backup node.The Controller manages beacons, task allocation, and revenue sharing.Source: §III · p. 2

A. System Workflow and Interactions

  • In each 5 ms slot, the Controller admits and allocates tasks using nominal estimates, then settles incentives from realized completion times and energy outside the execution critical path.The two stages are pipelined, so settlement time does not enter a task’s delay budget.Source: A. System Workflow and Interactions · p. 3, Figure 1 · p. 3

IV. SYSTEM MODEL

  • The system model treats tasks as input, output, workload, and deadline tuples, and considers the cloud plus the top-ranked available vehicles as candidate executors.The candidate set includes up to min(|Tz|, Mveh) vehicles, where Mveh is the number currently in coverage and available for offloading.Source: §IV · p. 3, A. Offloading Time · p. 3

A. Offloading Time

  • Estimated offloading time includes transmission, propagation, network, scheduling, computation, and executor queueing delays.Each executor is modeled as a single-server queue; its waiting-time estimate reflects service rate, routed arrival rate, and utilization.Source: A. Offloading Time · pp. 3–4

B. Energy and Cost Model

The energy and cost model measures infrastructure-side energy per task and represents stakeholder costs as random variables. It accounts for energy on the operator, executor, and network paths while excluding user-equipment uplink energy from the analysis.

B. Energy and Cost Model

  • The model excludes UE uplink energy because it is exogenous to the system and cannot be controlled or optimized by it.The analysis therefore focuses on infrastructure-side energy consumption.Source: B. Energy and Cost Model · p. 5
  • The Network Operator’s energy includes transmission to the executor, task-allocation computation, and 5G downlink transmission to the UE.Transmission to a vehicle uses a 5G wireless link, while transmission to the cloud uses the Internet.Source: B. Energy and Cost Model · p. 5
  • Vehicle and cloud executor energy covers task computation and output transmission, with radio energy modeled differently from wired cloud backhaul energy.Compute energy is metered per operation; the cloud’s backhaul transmission is charged at a constant energy intensity per transported bit.Source: B. Energy and Cost Model · p. 5
  • Energy-related stakeholder costs are stochastic because energy consumption and network conditions vary, while task parameters are fixed upon arrival.The cost model converts energy to cash using a stakeholder-specific rate.Source: B. Energy and Cost Model · p. 5

V. TASK ALLOCATION PROBLEM

The allocation problem assigns tasks to executor nodes to generate system-wide utility while respecting deadlines and executor quotas. It uses nominal estimates for decisions, then updates costs and incentives using realized execution outcomes.

V. TASK ALLOCATION PROBLEM

  • Decisions use nominal estimates because random-variable realizations are unknown at allocation time; reported execution outcomes later support cost recomputation and revenue sharing.Executors that systematically over-declare spare capacity are filtered before allocation by the admission rule.Source: §V · pp. 5–6
  • The allocation ranks candidate pairs by expected margin weighted by the residual slack remaining before the deadline.The slack term includes estimated completion time and favors pairs that leave more time margin when profitability is equal.Source: §V · pp. 5–6
  • Candidate task–executor pairs whose estimated completion time exceeds the deadline are excluded before the utility optimization.The allocation uses declared per-slot task quotas for each executor.Source: §V · pp. 5–6

A. Robust Admission

The robust admission rule screens task–executor pairs before optimization, guarding deadline-constrained allocation against overstated vehicle capacity. It combines a misreport measure with a tail-cost measure.

A. Robust Admission

  • Over-declaration is measured against realized capacity, while the second admission quantity captures the tail of offloading cost.The over-declaration measure is zero for truthful or conservative executors and grows with the fraction by which capacity is overstated.Source: A. Robust Admission · p. 6
  • A task–executor pair is admitted only if its estimated completion meets the task deadline and the robust admission test passes.The admission loop applies both checks before the final optimization.Source: A. Robust Admission · p. 6
  • The misreport penalty scales with the task payment and forfeits a fraction proportional to relative over-declaration; the evaluation sets the generic mismatch radius to zero.Thus the measured protection is attributable to the misreporting term alone.Source: A. Robust Admission · p. 6
  • The admission loop uses O(|Tz| |Ez|) scalar tests, and the final integer program runs well under the 5 ms slot at the evaluated loads.The algorithm collects beacons, ranks vehicles, checks candidate pairs, and dispatches admitted tasks.Source: A. Robust Admission · p. 6

VI. REVENUE SHARING VIA COOPERATIVE GAME THEORY

The paper models revenue sharing among the network operator and selected executors as a coalitional game. Its core defines stable, efficient payoff allocations that satisfy every coalition’s rationality constraint.

VI. REVENUE SHARING VIA COOPERATIVE GAME THEORY

  • The players are the selected executors and the network operator, and each coalition’s value is the maximum utility it can achieve independently.A payoff allocation is efficient when it distributes the grand coalition’s full value.Source: §VI · pp. 6–7
  • An allocation belongs to the core when it is efficient and every coalition receives at least its own value, leaving no subgroup incentive to deviate.Source: §VI · p. 7
  • End-users’ implicit reward is latency minimization: tasks are accepted and executed only when they meet strict end-to-end delay requirements.Source: §VI · p. 7

A. Robust Coalitional Game

The paper defines a stochastic transferable-utility game for the operator and selected executors, then establishes core non-emptiness under its assignment and payoff-weight conditions. Payments and realized costs determine the payoff distribution, including when tasks miss deadlines.

A. Robust Coalitional Game

  • The operator receives half of the realized payoff, and the selected executors divide the other half in proportion to their realized energy costs.The operator and executor group each absorb half of a realized deficit as well.Source: A. Robust Coalitional Game · p. 7
  • The outer game is solved in O(1) and the inner game in O(|Sz|); if core constraints fail, a correcting linear program runs in polynomial time.The authors state that this remains compatible with real-time operation for coalitions of tens of nodes.Source: A. Robust Coalitional Game · p. 7
  • A task earns payment only when it completes by its deadline; otherwise revenue vanishes while realized cost remains, so sustained misreporting strictly decreases the misreporter’s payoff.Source: A. Robust Coalitional Game · p. 7
  • Coalition values are stochastic because outcomes change realized costs and collected payments, while transferable utility allows value to be redistributed among players.The operator’s infrastructure and orchestration services are central to coalition value.Source: A. Robust Coalitional Game · pp. 7–8
  • For each slot and realization, the robust game has a non-empty core when tasks are assigned to at most one executor and the payoff weights are nonnegative and sum to one.The result establishes balancedness and core non-emptiness for the weighted game.Source: A. Robust Coalitional Game · p. 8

VII. SIMULATION FRAMEWORK

The simulation framework averages results over independent seeds with confidence intervals and uses a theoretical, conservative payment tariff approximation. It sweeps the fraction of vehicle computing capacity reserved for offloading.

VII. SIMULATION FRAMEWORK

  • Each simulation point averages 10 independent seeds and reports 95% Student-t confidence intervals, with interval overlap used as the significance criterion.Source: §VII · p. 8
  • Per-task payment is anchored to the Amazon Web Services Lambda 2026 tariff at 10 tasks/s per user, treated as a conservative theoretical approximation because public real-world measurements are unavailable.Source: §VII · p. 8
  • Vehicles’ spare offloading capacity is swept from 1% to 20% of total compute capacity, with most resources reserved for higher-priority functions.The evaluated fractions are 1, 3, 5, 8, 10, 15, and 20%.Source: §VII · p. 8

A. Experimental Scenario

The evaluation models a single 5G micro-cell using downtown Rome mobility and varies vehicle density, spare capacity, and the share of vehicles overstating capacity. Task sizes span four orders of magnitude, motivating an M/G/1 service-time model.

A. Experimental Scenario

  • The scenario varies vehicle density from 10 to 200, spare-capacity fraction, and the fraction ψ overstating capacity at fixed intensity 0.6.The end-user sweep from 25 to 200 is reported in supplementary material.Source: A. Experimental Scenario · p. 8
  • A downtown Rome SUMO trace feeds a single 5G micro-cell with a 500 m serving radius, so vehicles enter and leave coverage during each run.Each measured 30 s run follows a 30 s warm-up to reach stationarity.Source: A. Experimental Scenario · p. 8
  • Task workloads span four orders of magnitude, producing heavy-tailed service times that require the M/G/1 model.Source: A. Experimental Scenario · p. 9

B. Mobility and Networking

The study uses realistic Rome traffic and 5G channel conditions, then compares the proposed scheme with alternatives that isolate admission and allocation choices. The comparison also includes vehicle, edge, and cloud baselines, with Table III reporting failure rates and realized utility under an honest fleet.

B. Mobility and Networking

  • Rome road and traffic traces drive mobility, while a 5G urban non-line-of-sight model and interference-aware rates represent radio conditions; inter-gNB handovers are excluded.The model uses one serving gNodeB and excludes handovers because their typical 80–120 ms duration exceeds the 5 ms decision window.Source: B. Mobility and Networking · p. 9

C. Compared Strategies

  • The five alternatives include no-admission and greedy allocation variants, a vehicle-prioritizing baseline, and edge-only and cloud-only service.DRO versus no-DRO isolates admission with optimality held fixed, while no-DRO versus Greedy isolates allocation optimality without admission.Source: C. Compared Strategies · p. 9
  • Payment and conversion-rate inputs are stylized and enter utilities linearly; energy costs remain orders of magnitude below revenues at all densities.Rescaling the two inputs rescales monetary curves while preserving net-utility signs.Source: C. Compared Strategies · p. 9
  • Table III reports failure rate and realized utility versus vehicle density; under honest reporting, DRO, no-DRO, and Greedy coincide within confidence intervals.Utility is net of tasks missing deadlines at execution; the table uses 10 seeds for aggregate means.Source: Table III · p. 9

VIII. SIMULATION RESULTS

As vehicle density rises, VCC takes over most offloaded tasks, while delay, energy use, and profitability vary with fleet density and capacity conditions. Robust admission reduces late failures from over-declaration in scarce-capacity regimes, but can cost utility when capacity is abundant.

A. Viability: Offloading Time and Failure Rate

  • Vehicles serve 97% of tasks at 30 vehicles and essentially all beyond 60, while mean completion time reaches 40 ms at 200 vehicles.At 10 vehicles, close to half of tasks go to the cloud and mean completion time is capped at 140 ms; the mean peaks at 150 ms at 30 vehicles.Source: A. Viability: Offloading Time and… · p. 9, Figure 2 · p. 10
  • Failure rates for the three exact policies fall from 48% at 30 vehicles to 13% at 200; Vehicles-first ranges from 62% to 5%.Edge-only remains below 3% everywhere; Vehicles-first is worst at low density but best among VCC strategies at high density, at several times the wasted cost.Source: A. Viability: Offloading Time and… · pp. 9–10

B. Energy Analysis

  • Vehicular execution costs 60–70 mJ per task versus about 118 mJ on the cloud path, while one offload is about 10^-7% of a Tesla Model S's energy per 100 km.The cloud's higher per-task energy is attributed to its Internet leg; energy costs remain three orders of magnitude below payments.Source: B. Energy Analysis · p. 10, A. Viability: Offloading Time and… · p. 10

C. Profitability: Utility and Incentive Distribution

  • Aggregate realized utility falls from 20.1 to 18.1×10^3 µ$ between 10 and 30 vehicles, then rises to 36.1 at 200.The minimum coincides with peak completion time and a 48% failure rate, when tasks occupy executors and then miss deadlines without earning payment.Source: C. Profitability: Utility and… · p. 10
  • Vehicle-owner revenue ranges from $4.13 to $0.87 per vehicle-month as density rises from 10 to 200 vehicles, equivalent to 157 to 33 km of monthly driving range.The calculation assumes 1 hour 20 minutes of daily driving in the covered area and an 18.4-year vehicle lifetime.Source: C. Profitability: Utility and… · p. 10, Table IV · p. 11
  • At full utilization, edge cost per served task is 84× VCC's and rises inversely with load, whereas VCC's cost curve is flat.The edge server amortizes a fixed three-year total cost of ownership; VCC has no capital cost to recover.Source: C. Profitability: Utility and… · p. 11, Table V · p. 11

D. Robustness to Capacity Misreporting

  • At 8% spare capacity and ψ = 0.6, DRO loses 5.3% of offered load to late failures versus 31.1% for no-DRO; at 3% capacity it avoids up to 11,516 failures.At 20% spare capacity, the sign reverses: DRO has 634 and 1,186 more failures than no-DRO at ψ = 0.6 and 0.8, respectively.Source: D. Robustness to Capacity Misreporting · p. 11, Figure 3 · p. 11
  • Robust admission improves net utility under scarce capacity but becomes significantly negative from 15% spare capacity onward; an adaptive penalty variant was tested and rejected.On an honest fleet, policies coincide apart from solver tie-breaking below 0.5% on a single seed.Source: D. Robustness to Capacity Misreporting · pp. 11–12

IX. CARBON EMISSIONS ANALYSIS

The carbon analysis estimates vehicle emissions across grid and fleet conditions and compares VCC with edge-server life-cycle emissions; the reported advantage remains under peak-share attribution.

A. Estimated Carbon Emissions per Vehicle

  • Vehicle emissions range from 6 to 300 g CO2 per year, decreasing with fleet density as more tasks use the lower-energy vehicular path.The range depends on grid carbon intensity and fleet density.Source: A. Estimated Carbon Emissions per… · p. 12

B. Vehicular vs. Edge Computing: Carbon Emissions

  • Over 99% lower life-cycle emissions, up to 8.5 t CO2 per vehicle over five years, are reported for VCC instead of deploying edge servers.The comparison includes production, operation, and end-of-life phases.Source: B. Vehicular vs. Edge Computing:… · p. 12

C. Peak-Load Attribution

  • Attributing edge-server emissions pro rata to offloading’s peak compute share scales the footprint and savings, but the comparison remains in VCC’s favor.The full-server attribution is described as an upper bound; the shared-server advantage narrows without inverting.Source: C. Peak-Load Attribution · p. 12

X. CONCLUSION

  • The conclusion reports small added vehicle emissions alongside reduced rare-element demand, while prototype and field validation remain next steps.The reported vehicle range is 6–300 g CO2 per year, and replacing an edge server saves up to 8.5 t CO2 over its life cycle.Source: §X · p. 13
Loading 2609.29731v1…