NP-Hard Joint Latency and Security Optimization for Task Offloading in IoT-Enabled Vehicular Networks

1. Introduction

The Internet of Things (IoT) connects many devices that generate large amounts of data. A large and fast-growing part of the IoT is the Internet of Vehicles (IoV). Connected vehicles generate large-scale data streams. These streams need low-latency processing and secure communication. Task offloading to Roadside Units (RSUs) and Edge Nodes (ENs) helps to address resource scarcity and reduce latency [1].

Task offloading and cryptographic security are usually studied as two separate problems. Most offloading strategies pick the best node for a task using latency and resource metrics [2]. They do not change the cryptographic settings during scheduling. They assume all tasks need the same fixed level of security. In a fast-changing vehicular IoT environment, this separation can cause two problems: either the system spends too much time on cryptography, or it does not protect tasks enough. Elliptic Curve Cryptography (ECC) gives strong security with a small computational cost, which makes it a good fit for resource-constrained vehicular networks [3,4,5,6,7]. However, most ECC systems use one fixed curve for every task [8]. A fixed curve can be refreshed for freshness, but it is still not linked to the scheduling decision.

Choosing the best combination of task-to-node assignment and cryptographic curve, for every task, at every scheduling window, is a hard combinatorial problem. We show in this paper that this joint problem contains a well-known NP-hard problem as a special case: the generalized assignment problem. This is one reason why, to our knowledge, no prior work solves the joint problem exactly at scale; instead, we design a fast, greedy heuristic, and we measure how close this heuristic gets to the true optimal solution using an exact solver.

This study asks four research questions:

• RQ1: How much does jointly optimizing latency and cryptographic security improve task success rate, compared to optimizing latency alone or using a fixed cryptographic curve?
• RQ2: How hard is the joint offloading and curve-selection problem, in a formal, complexity-theoretic sense?
• RQ3: How far is a fast, greedy heuristic from the true optimal solution, and does this gap change with system load?
• RQ4: Is the extra cryptographic overhead small enough for real-time vehicular IoT deployment?

To answer these questions, this study proposes a dynamic joint latency-security offloading model. The model treats curve selection as an adaptive decision variable. It jointly optimizes this decision alongside latency, CPU load, bandwidth availability, and task priority. The model keeps cryptographic resilience while adapting to the fast-changing security needs of vehicular IoT environments, by selecting curves from both standard and non-standard curve pools.

Recent work has studied related problems. [22] combine lightweight identity-based cryptographic authentication with deep-reinforcement-learning-based task offloading in 6G vehicular twin networks. [23] propose a security-aware task offloading framework for IoT edge networks that uses Software-Defined Networking (SDN) and a lightweight heuristic decision engine. Both works, like the present study, treat security and offloading as a joint problem rather than two separate ones. However, neither work gives a formal complexity analysis of the joint problem, and neither compares its heuristic against an exact solver. This is the specific gap the present paper addresses.

The main contributions of this paper are summarized as follows:

• Dynamic ECC-Aware Offloading Model: A novel joint latency-security task offloading model that adapts elliptic curve configurations in response to changes in the vehicular edge offloading context.
• Unified Performance-Security Optimization: A joint scoring mechanism that balances key performance metrics (latency, resource utilization, and bandwidth) with cryptographic metrics (security strength and curve freshness).
• Formal Complexity Analysis: We show that the joint offloading and curve-selection problem reduces to a generalized assignment problem, a well-known NP-hard problem, when curve-selection variables are fixed, and we quantify the resulting optimality gap of the proposed heuristic against an exact Integer Linear Programming (ILP) solver.
• Real, Openly Available Evaluation: Compared with static ECC-based and latency-only techniques, a Python simulation with openly available code shows task completion rates within a fraction of a percentage point of latency-only scheduling, far higher than static ECC, together with substantially improved cryptographic robustness (more than a 10-fold reduction in replay success) and minimal additional overhead.

2. Related Work

Task offloading in resource-limited edge environments has been studied a lot, to improve computational efficiency [9,10]. Traditional approaches model offloading as an optimization problem. They minimize latency and energy, using game-theoretic methods, deep reinforcement learning, or mixed-integer nonlinear programming [11]. Despite these advances, most performance-centric schemes treat security as fixed. They do not link security to the offloading decision [12].

Recent security-aware approaches add authentication and trust metrics. They use security-aware reinforcement learning or blockchain-based solutions [13,14]. However, their objectives focus on trust assessment and access control. Their encryption mechanisms use fixed cryptographic parameters. These parameters do not respond to network changes. In IoT and vehicular applications, ECC is now common, because it has a smaller key size and lower computational overhead [15]. Standardized curves, such as NIST P-256 and Curve25519, remain the default choice [16,17]. However, curve selection is still independent of system-level task scheduling [18].

Some work studies dynamic cryptographic adaptation in vehicular edge systems. Existing dynamic ECC approaches typically rely on predefined sets of standardized curves with constrained switching mechanisms [8]. Although such methods improve key freshness, curve selection is generally decoupled from task scheduling and offloading decisions. The treatment of elliptic curve selection as an optimization variable jointly linked to task priority, network conditions, and performance constraints remains largely unexplored. Moreover, the systematic evaluation of curve diversity, including standardized and non-standard curves, as a resilience-enhancing strategy has received limited attention in vehicular edge computing.

More recent security-aware offloading frameworks have the same limitation. [20] propose a deep-reinforcement-learning offloading framework for vehicular edge-cloud computing. This framework targets energy efficiency and security together. [21] combine federated learning with blockchain to secure traffic-rerouting and task-offloading decisions in the Internet of Vehicles. However, these approaches, like [13,14], treat security as an authentication, trust, or access-control layer. They do not co-optimize an adaptive cryptographic parameter with the offloading decision itself. The same gap identified above remains open across all of this related work. Table 1 summarizes this positioning, using standard abbreviations: DRL (deep reinforcement learning), RL (reinforcement learning), FL (federated learning), and IBC (identity-based cryptography).

3. System Model and Problem Definition

We consider a dynamic vehicular edge environment in which mobile vehicles generate computation tasks that are offloaded to edge-processing nodes, including RSUs and ENs.

3.1. Sets and Indices

• $\mathcal{T}=\{1,\dots ,N\}$: Set of tasks, indexed by i.
• $\mathcal{N}=\{1,\dots ,M\}$: Set of edge nodes, indexed by j.
• $\mathcal{K}=\{1,\dots ,K\}$: Set of available ECC curves, indexed by k.

Task i requires ${\mathrm{comp}}_i$ (CPU cycles), ${\mathrm{data}}_i$ (input Mb), has ${\mathrm{deadline}}_i$ (ms), and minimum security ${\sec }_i$ (bits). Node j has CPU frequency $f_j$ (MHz), utilization ${\rho }_j$, bandwidth $B_j$ (Mbps), and ECC freshness age ${\tau }_j$. Curve k provides security $S_k$ (bits) and overhead $O_k$ (ms).

Table 2 summarizes the workload, node, and ECC curve parameters used in the system model. We consider a discrete scheduling window of duration $\Delta$ s. The available computational capacity is $C_j=f_j(1-{\rho }_j)\Delta$. Decision variables: $x_{ij}\in \{0,1\}$ (task i assigned to node j), $y_{jk}\in \{0,1\}$ (node j selects curve k). Once a node has selected a curve, we write $S_j={\sum }_{k\in \mathcal{K}}{y}_{jk}{S}_k$ for the security strength of node j’s currently selected curve, used below in (C3) and in the scoring function.

The end-to-end delay is:

$$d_{ij}={\displaystyle \frac{1000·{\mathrm{data}}_i}{B_j}}+{\displaystyle \frac{1000·{\mathrm{comp}}_i}{f_j(1-{\rho }_j)}}+{\displaystyle \sum _{k=1}^K}{y}_{jk}{O}_k,$$

(1)

with transmission time, execution time, and cryptographic overhead.

3.2. Freshness Model

Freshness is modelled as ${\tau }_j\left(t\right)=t-t_j^{\mathrm{upd}}$, where $t_j^{\mathrm{upd}}$ is the most recent update time. Larger update intervals increase replay risk and retransmission likelihood.

3.3. Optimization Problem

We maximize a unified performance–security objective:

$$\underset{\{x_{ij},y_{jk}\}}{max}\sum _{i\in \mathcal{T}}\sum _{j\in \mathcal{N}}{x}_{ij}{\mathrm{Score}}_{ij}$$

(2)

subject to

$$\begin{array}{cc}\hfill & \sum _{j\in \mathcal{N}}{x}_{ij}=1,\forall i\in \mathcal{T}\hfill \end{array}$$

(C1)

$$\begin{array}{cc}\hfill & x_{ij}{d}_{ij}\le x_{ij}{\mathrm{deadline}}_i,\forall i\in \mathcal{T},j\in \mathcal{N}\hfill \end{array}$$

(C2)

$$\begin{array}{cc}\hfill & x_{ij}{S}_j\ge x_{ij}{\sec }_i,\forall i\in \mathcal{T},j\in \mathcal{N}\hfill \end{array}$$

(C3)

$$\begin{array}{cc}\hfill & \sum _{i\in \mathcal{T}}{x}_{ij}{\mathrm{comp}}_i\le C_j,\forall j\in \mathcal{N}\hfill \end{array}$$

(C4)

$$\begin{array}{cc}\hfill & \sum _{i\in \mathcal{T}}{x}_{ij}{\mathrm{data}}_i\le B_j\Delta ,\forall j\in \mathcal{N}\hfill \end{array}$$

(C5)

$$\begin{array}{cc}\hfill & \sum _{k\in \mathcal{K}}{y}_{jk}=1,\forall j\in \mathcal{N}\hfill \end{array}$$

(C6)

$$\begin{array}{cc}\hfill & x_{ij},y_{jk}\in \{0,1\}\hfill \end{array}$$

(C7)

Constraint (C1) ensures that each task is assigned to one node. Constraint (C2) ensures deadline feasibility. Constraint (C3) ensures that the selected curve strength $S_j$ satisfies the required security level. Constraints (C4) and (C5) impose computational and bandwidth-capacity limits. Constraint (C6) ensures that each node selects one ECC curve. Finally, (C7) specifies the binary assignment and curve-selection variables. The unified performance–security score is:

$${\mathrm{Score}}_{ij}=\alpha {\widehat{d}}_{ij}+\beta {\widehat{\rho }}_j+\gamma {\widehat{S}}_j+\delta {\widehat{\tau }}_j,\alpha +\beta +\gamma +\delta =1,$$

(3)

where normalized metrics balance performance (delay, load) and security (strength, freshness). Using this formulation, cryptographic agility is incorporated into task assignment.

4. Curve-Aware Model Architecture

4.1. System Architecture

Figure 1 depicts the three-layer architecture of the proposed model. The Vehicle Layer has mobile task requesters that generate computational tasks and communicate them via a wireless link. The Edge Layer has RSUs and ENs that execute offloaded tasks and each node has a live state tuple $({\rho }_j,B_j,{\tau }_j)$. The Optimization and Control Layer operates the offloading controller, which (i) reads node states and the ECC curve pool $\mathcal{K}$, (ii) selects a curve $k^{*}$ for each node, (iii) scores each candidate assignment, and (iv) assigns tasks to the best-scoring viable node. After each scheduling window $\Delta$, the controller receives the updated node states and freshness counters.

4.2. Proposed Offloading Algorithm

Algorithm 1 operationalizes the optimization model by assessing viable nodes under time, security, and remaining-capacity restrictions, and selecting the node with the highest performance–security score. Remaining capacity is tracked and decremented as tasks are assigned within the window, enforcing (C4)-(C5) directly rather than as a separate post-hoc check. Ties are implicitly resolved by retaining the first encountered maximum score owing to the strict update rule. Curve selection (which curve a node uses) is not part of this per-window procedure; it happens separately, only when a node’s freshness triggers a refresh (Section 5.1).

Algorithm 1 Dynamic Curve-Aware Secure Task Offloading

Require:  Task set $\mathcal{T}$, node set $\mathcal{N}$ Ensure:  Assignment mapping $\mathcal{M}$   1: for all $j\in \mathcal{N}$ do   2:     ${\mathrm{remComp}}_j\leftarrow C_j$, ${\mathrm{remData}}_j\leftarrow B_j\Delta$▹ reset remaining capacity, Eq. (C4)-(C5)   3: end for   4: for all $i\in \mathcal{T}$ do   5:     $\mathrm{bestScore}\leftarrow -\infty$, $\mathrm{bestNode}\leftarrow \varnothing$   6:     for all $j\in \mathcal{N}$ do   7:         Compute $d_{ij}$   8:         if Constraints (C2) and (C3) are satisfied and ${\mathrm{comp}}_i\le {\mathrm{remComp}}_j$ and ${\mathrm{data}}_i\le {\mathrm{remData}}_j$ then▹ (C4)-(C5)   9:            Compute ${\mathrm{Score}}_{ij}$ 10:            if ${\mathrm{Score}}_{ij}>\mathrm{bestScore}$ then 11:                $\mathrm{bestScore}\leftarrow {\mathrm{Score}}_{ij}$, $\mathrm{bestNode}\leftarrow j$ 12:            end if 13:         end if 14:     end for 15:     if $\mathrm{bestNode}\ne \varnothing$ then 16:         Assign task i to bestNode; ${\mathrm{remComp}}_{\mathrm{bestNode}}-={\mathrm{comp}}_i$; ${\mathrm{remData}}_{\mathrm{bestNode}}-={\mathrm{data}}_i$ 17:     end if 18: end for 19: return$\mathcal{M}$

5. Evaluation and Results

5.1. Experimental Setup

We evaluate the model in Section 3 using a Python discrete-event Monte Carlo simulation. The results in this section come from the Python code described below, which is openly available (see Data Availability).

The simulation runs in scheduling windows of $\Delta =5$ s, matching Table 3. Each window generates a new batch of tasks and assigns them to nodes (10 RSUs, 5 ENs), following Algorithm 1. A full run covers 1000 s (200 windows), matching the duration in Table 3. Node freshness ${\tau }_j$ increases by $\Delta$ each window and resets to zero when a node refreshes. Dynamic ECC refreshes every U seconds (default 60 s). Static ECC never refreshes within a run. Latency-Only uses no cryptography at all: it pays zero ECC overhead, structurally, by never invoking a curve (see Section 5.1.1 for the overhead the other two strategies do pay).

Two mechanisms tie staleness to the results we report. First, a replay attempt against a node succeeds with probability $min(1,{\tau }_j/T_{\mathrm{ref}})$, where $T_{\mathrm{ref}}=300$ s is the paper’s own maximum curve-update interval from Table 3. This formalizes the claim that a longer replay window follows directly from a longer update interval. Second, a session on a stale node has the same probability of needing one retry, which costs one extra transmission round-trip. This is what lets staleness cost time, not only security.

5.1.1. ECC Overhead per Curve

We measure the cryptographic cost of each curve directly. For each curve, we timed 300 full handshakes (key generation, Elliptic Curve Diffie-Hellman (ECDH) exchange, sign, verify) using Python’s cryptography library [26], after a warm-up phase to remove first-call noise. Table 4 reports the results.

The curve pool excludes secp160r1, which has been removed from modern OpenSSL-backed cryptography libraries for being under-strength and is no longer usable in current deployments. Instead, the pool pairs two NIST/SECG (Standards for Efficient Cryptography Group) prime curves (secp192r1, secp224r1) with Curve25519 (X25519 for key exchange, Ed25519 for signing), a real, RFC 7748-standardized curve [24] from a different mathematical family (Montgomery form). This gives the pool genuine standard/non-standard-family diversity, spanning two distinct curve designs rather than three variants of the same one.

The measurement produced a genuinely unexpected finding: secp192r1 is slower than secp224r1, even though it is the weaker curve. This is most likely explained by secp192r1 being old and rarely used in current deployments, so it falls back to generic field arithmetic, while secp224r1 and Curve25519 get optimized fast paths in modern OpenSSL implementations.

The scoring function implemented is exactly Eq. (3), with normalization references $d_{max}=1300$ ms (the maximum task deadline in Table 3, the natural ceiling for any delay that could pass constraint (C2)), ${\tau }_{max}=300$ s (equal to $T_{\mathrm{ref}}$), and $S_{max}=128$ bits (the strongest curve in Table 4).

5.2. Baselines and Overall Comparison

We compare Latency-Only, Static ECC, and Dynamic ECC over 30 independent 1000 s runs. Table 5 reports task success rate (TSR) and replay success, with 95% confidence intervals.

Dynamic ECC and Latency-Only land at essentially the same TSR (85.27% vs. 85.58%, a difference well inside the confidence intervals). Dynamic ECC does not win on task success. What it wins is security, at almost no cost: replay success falls from 100% (no protection at all) to 8.93%, more than a 10-fold reduction, while TSR barely moves.

Static ECC is the clear loser on both counts. It fixes one curve (secp224r1, 112-bit security) for the whole run. Two things follow. First, any task requiring 128-bit security (a real fraction of tasks in our model, since security requirements are drawn from {80, 96, 112, 128} bits) cannot be served at all, which alone caps its achievable TSR well below the other two strategies. Second, because it never refreshes, its freshness grows without bound across the 1000 s run; once past $T_{\mathrm{ref}}=300$ s, essentially every session on it is both maximally replay-vulnerable and paying the retransmission penalty, which drags TSR down further. Static ECC performs worse than no security at all, not because static cryptography is inherently bad, but because a single fixed curve, never refreshed, fails a predictable slice of tasks by design and accumulates staleness with no bound.

A paired two-sided t-test confirms both differences are far outside noise: Dynamic ECC vs. Static ECC, TSR $t=213.79$, replay success $t=530.49$ (both $p<0.001$).

5.3. Scalability with Vehicle Volume

We scaled the scenario from 50 to 300 vehicles, with the task arrival rate per window scaled proportionally (26 tasks per window at the 100-vehicle default, roughly 0.26 tasks per vehicle per window, since not every vehicle sends a task in every 5 s window). Figure 2a and Figure 2b report TSR and average latency.

TSR degrades gradually for all three strategies as vehicle count grows (Dynamic ECC: 85.40% at 50 vehicles to 83.58% at 300; Latency-Only: 86.02% to 82.42%; Static ECC stays flat near 40% throughout, since its TSR ceiling is set by the security-mismatch and staleness problems described above, not by load). Average latency rises modestly with load for all strategies. Dynamic ECC’s latency stays close to Latency-Only’s (429–453 ms vs. 337–370 ms across the range), with the gap coming almost entirely from Curve25519’s measured 0.34 ms overhead plus occasional retry cost, not from the curve-selection logic itself.

5.4. Freshness Sensitivity (Update Interval)

We varied the refresh interval U for Dynamic ECC and measured TSR and replay success (Table 6, Figure 2c).

Replay success grows with U, roughly doubling as U doubles, which is exactly what the linear-in-staleness replay model predicts and a useful sanity check that the mechanism behaves as designed. TSR shows a threshold effect rather than a steady decline: it drops only modestly from $U=30$ s to $U=120$ s, then falls sharply at $U=300$ s, once nodes spend most of the run past the $T_{\mathrm{ref}}$ staleness threshold and pay the retransmission penalty on most tasks. This threshold behavior is itself a useful, actionable finding: it means the operator does not need to refresh very aggressively to stay safe, only avoid the long-interval regime where the penalty compounds.

5.5. Latency–Security Trade-off

Figure 2d plots average latency against replay success for the three strategies at default load. Latency-Only sits at the lowest latency and, by construction, the highest replay success (100%): it has no way to trade one for the other. Static ECC sits at higher latency and still high replay success, the worst of both. Dynamic ECC is close to Latency-Only on latency while cutting replay success by more than a factor of 10, which is the trade-off this paper’s design is meant to offer.

5.6. Latency Distribution (CDF)

Figure 3a shows the empirical cumulative distribution function (CDF) of end-to-end latency for all three strategies, pooled across 10 independent runs (tens of thousands of samples per strategy). Latency-Only has the tightest, left-most distribution (median 329 ms), since it pays no cryptographic or retry cost. Dynamic ECC sits close behind (median 389 ms). Static ECC has the widest, right-shifted distribution (median 524 ms, heaviest tail), consistent with it accumulating staleness and paying the retransmission penalty on most of its sessions over a 1000 s run.

5.7. CPU Utilization vs. Load

Figure 3b reports average node CPU utilization as vehicle count scales from 50 to 300. Utilization rises roughly linearly with load for all three strategies but stays low in absolute terms (0.6%–8.9% across the range and all three strategies at default node counts), reflecting generously provisioned node capacity relative to task load in this configuration. We note this explicitly because it also explains a null result in Section 5.8: capacity is rarely the binding constraint at default load, so which specific feasible node a task prefers rarely changes whether it succeeds.

5.8. Ablation on Scoring Weights

At the paper’s default load, the four scoring weights $(\alpha ,\beta ,\gamma ,\delta )$ have no measurable effect on TSR or replay success: with utilization under 4% (Section 5.7), there is essentially always spare capacity somewhere, so node preference rarely determines whether a task succeeds, and replay success is governed entirely by the refresh schedule, not by node choice.

To give the ablation a real chance to matter, we re-ran it under a high-load, capacity-constrained condition (300 tasks per window, roughly 42% average utilization). Table 7 reports the result.

Under contention, a small, monotonic effect appears: TSR rises slightly as weight shifts from latency-focused to security-focused (66.10% to 66.69%, under one percentage point of spread). Replay success does not move at all across configurations (8.93% throughout), which makes sense: replay success is set entirely by the refresh interval, a schedule the scoring weights do not touch.

5.9. Robustness to Network Jitter and Attack Intensity

Figure 3c reports deadline miss ratio (100−TSR) against network jitter range, for Static and Dynamic ECC. Miss ratio rises with jitter for both, from 58.72% to 62.97% for Static ECC and from 13.63% to 19.10% for Dynamic ECC across the tested ranges (0–5 ms up to 30–120 ms). Dynamic ECC’s miss ratio stays well below Static ECC’s at every jitter level tested.

Figure 3d reports the effect of replay attack intensity. Here we report absolute compromised-session counts rather than a success percentage, because the percentage is, by construction, mostly independent of attack rate in this model: it is a per-attempt conditional probability that depends on staleness, not on how many attempts occur. What does scale with attack intensity is the raw number of compromised sessions, which rises close to linearly with attempt rate for both strategies, as expected from the underlying Poisson attempt process. At every attack rate tested (0.2 to 5.0 attempts/s per node), Dynamic ECC shows roughly 9-fold fewer compromised sessions than Static ECC (e.g., 274 vs. 2540 at the default rate; 6787 vs. 63,561 at the highest rate tested). We do not currently model a feedback loop from a successful replay back into task assignment or TSR; extending the model so that a compromised session forces a costly recovery is a direction for future work, not a claim we make here.

5.10. Threat Model and Adversary Assumptions

We assume a passive-to-active on-path or in-range wireless adversary who can eavesdrop on task-offloading exchanges, record previously observed authenticated messages, and replay them at a later scheduling window. We do not assume the attacker holds any legitimate node’s private key, and we do not assume the attacker can break the underlying elliptic-curve discrete-logarithm problem for the curve strengths in Table 4. The attack surface modeled here is protocol-level replay, not cryptanalytic key recovery.

Under this model, freshness ${\tau }_j$ is the replay countermeasure, implemented directly as described in Section 5.1: replay success probability is $min(1,{\tau }_j/T_{\mathrm{ref}})$, so the attacker’s effective replay window is bounded by the refresh interval U. This is why replay success degrades monotonically with U in Table 6: a larger U directly and mechanically enlarges the attacker’s window, rather than merely correlating with it. Collusion between compromised nodes, location spoofing, and Sybil identities are outside the scope of this model and are left for future work.

5.11. Runtime Feasibility

We measure the wall-clock runtime of Algorithm 1 directly. At the paper’s default load (26 tasks per window, 15 nodes), 100 trials give a mean runtime of 0.481 ms per scheduling window (p95: 0.790 ms), against the $\Delta =5000$ ms window budget: a margin of roughly 10,000×. Even at 100 tasks per window, mean runtime is 1.709 ms, a margin of roughly 2900×, confirming real-time feasibility with a wide margin.

5.12. Optimality Gap Against an Exact ILP Bound

We solved the assignment problem exactly with a Mixed-Integer Linear Programming (MILP) solver (CBC via PuLP [25]), using the identical realized delay and score matrix the greedy heuristic sees for each instance, so that any gap reflects the assignment strategy and not different random draws. Table 8 reports the result at two scales.

At reduced scale, the heuristic matches the ILP optimum exactly in every seed tested. At the paper’s full default scale, the mean gap is a small 2.34%, with individual seeds ranging from 0.22% to 7.06%. This confirms the heuristic is a genuinely close approximation to the optimal assignment at both scales tested, not merely a fast one.

5.13. Limitations

This evaluation has real boundaries worth stating plainly. It is a Python discrete-event Monte Carlo simulation, not a full network simulator: it does not model vehicle mobility, physical-layer wireless propagation, or a packet-level network stack. Node and task parameters are drawn from the ranges in Table 3. ECC overhead is measured on one evaluation machine, not across a range of embedded hardware. The replay-attack model is a documented, simple mechanism (Section 5.1), not a proof; a successful replay does not currently feed back into task assignment or TSR, which we flag explicitly in Section 5.9 as future work rather than a present claim. The scoring-weight ablation shows a real but small effect that only appears under a high-load condition constructed to produce capacity contention; at the paper’s own default load, the four weights are inert. Extending this evaluation to a full mobility and network-layer simulator, and closing the small remaining ILP gap with a local-search refinement of Algorithm 1, are both directions for future work.

6. Conclusions

This paper has presented a joint latency-security task offloading model for vehicular edge environments, where ECC curve selection and freshness are integrated directly into the task assignment optimization process. We evaluated it with an openly available Python simulation. The main finding is that dynamic ECC gets almost all of Latency-Only’s task success rate (85.27% vs. 85.58%, a difference inside the confidence interval) while cutting replay success by more than a factor of ten (8.93% vs. 100%). Static ECC, a single fixed curve that never refreshes, is the clear loser on both counts: it cannot serve tasks that need stronger security than its one curve provides, and it accumulates staleness with no bound, so its TSR (40.29%) sits far below both alternatives. Measured cryptographic overhead is small, 0.34–1.19 ms depending on the curve, and the heuristic’s measured runtime leaves a wide margin (roughly 10,000×) against the scheduling window. Against an exact ILP bound, the heuristic is optimal at reduced scale and within 2.34% at the paper’s full default scale. Section 5.13 discusses what this evaluation does not yet cover and outlines directions for future work.