{"id":"1b88a8a3-bc64-42c9-a7db-773dd1f3fe1f","arxiv_id":"2411.15989","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":3,"one_line_summary":"A suitability-score-based resource selection algorithm with a resource reservation mechanism improves simulated task completion rates for autonomous driving workloads in heterogeneous edge computing.","lead":"This paper proposes two scheduling heuristics, SARS and PORA, for choosing edge-computing processors that should run real-time tasks from autonomous vehicles. In a small synthetic simulation, the combined algorithm completes up to 13% more tasks than the baseline server-selection rules it compares against.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The suitability score in Eq. (8) adds β·lf, so more-loaded PUs score higher, contradicting the stated load-balancing goal; with α unreported and crossing 1, the claimed 13% gain lacks a supported mechanism.","rationale":"The reader's weakest assumption was parameter tuning on the same simulation. I agree that tunability is a reproducibility threat, but the more load-bearing problem is internal: Eq. (8) as written implements the opposite of load balancing. A positive β·lf term makes heavily loaded PUs more attractive, and the α range spans a sign reversal in the dependence on completion time. Because the paper never states the chosen α, the reader cannot tell whether SARS behaved as a latest-deadline selector, an earliest-completion selector, or something in between. This directly undermines the causal story behind the headline claim, not just its generalizability. The PORA algorithm's 'top k' parameter is also undefined (Algorithm 2, Line 11), and no seeds or error bars are reported, but the scoring-function issue is the most fundamental because it affects the core selection rule in every experiment. The paper remains a plausible engineering study, and the empirical result may survive correction, so the conditional verdict is appropriate. Additional conditions should include reporting the exact α, defining k, providing code or seeds, and either correcting Eq. (8) to a negative load term or explaining why a positive load term is intended.","tokens_in":11799,"tokens_out":5535,"duration_ms":55577,"concrete_test":"Re-run the Section 5.2 comparison with Eq. (8) changed to ss = t_ct + α·tm − β·lf, keeping all other settings and the reported α/β values, and report TCR for each TSP algorithm. Also run α = 0.5 and α = 1.5 as sensitivity checks and report the actual α and PORA k used. If the 13% gain disappears or reverses under the sign flip, the published scoring formula is not the one that produced the headline result.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central empirical claim rests on the SARS suitability score defined in Eq. (8): ss = t_ct + α·tm + β·lf. Since tm = deadline − t_ct, for a fixed deadline this is ss = α·deadline + (1−α)·t_ct + β·lf. For α ∈ [0.5, 1.5], the algorithm's preference reverses at α = 1: α < 1 favors later-completing PUs, α > 1 favors earlier-completing PUs. The paper never reports the actual α used in Section 5.2, only that it was tuned 'by trial-and-error' in that range, so the tested behavior is unreproducible. More seriously, Eq. (8) adds β·lf, where lf = current load / max load. A high load should make a PU less attractive, but a positive coefficient makes high-load PUs receive higher scores and therefore be selected more often. This directly contradicts Section 4.1, which states that the load factor 'ensures that highly utilized PUs are less likely to be allocated to additional tasks, promoting balanced resource usage.' If the implementation actually subtracted β·lf, the text is wrong; if it followed Eq. (8) as written, the claimed improvement cannot be attributed to the proposed balancing mechanism. Either way, the published algorithm cannot be reproduced as described, and the up-to-13% TCR advantage may be an artifact of one tuned scoring direction rather than the designed load-aware selection.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper addresses resource selection in heterogeneous mobile edge computing for autonomous-driving real-time tasks. It proposes SARS, a suitability-based resource selection algorithm that scores each processing unit (PU) using completion time, time margin, and a load factor, and PORA, a proactive reservation mechanism that keeps certain PUs on standby for critical tasks. The experimental section compares SARS and SARS+PORA against classical RSP baselines (shortest-execution, random, latest-PU) across six TSP algorithms and reports task completion rate (TCR) improvements, including up to 13% over the shortest-execution PU baseline when PORA is enabled.","tokens_in":12027,"tokens_out":3556,"duration_ms":30993,"significance":"If the reported improvements are robust, the paper offers a simple, practical addition to the RSP component of task offloading in MEC, which is often under-studied relative to TSP. The algorithms are clearly described with pseudocode, and the paper considers realistic factors such as heterogeneity, distance-dependent transmission delays, and load balancing. However, the quantitative claims as stated are not supported by the current evaluation: the suitability score in Eq. (8) appears to reward high load rather than penalize it, the actual tuned parameters are not reported, the PORA top-k parameter is undefined, and the results lack statistical validation. The central algorithmic idea is defensible, but the evaluation must be corrected and made reproducible before the numeric claims can be accepted.","major_comments":[{"comment":"The suitability score in Eq. (8) adds β·lf, where lf is defined in Eq. (7) as the current load divided by the maximum load. Since Algorithm 1 (Line 12) selects the PU with the maximum suitability score, a positive β makes more heavily loaded PUs more attractive, which directly contradicts the text in Section 4.1 stating that the load factor 'ensures that highly utilized PUs are less likely to be allocated to additional tasks, promoting balanced resource usage.' Either Eq. (8) should use −β·lf, or the text must be revised to describe the actual behavior; as written, the algorithm is not reproducible and the claimed load-balancing benefit has no supporting mechanism.","section":"Section 4.1, Eq. (8)"},{"comment":"The paper states in Section 5.1 that α was tuned by trial-and-error within the range 0.5 to 1.5, but it never reports the actual value used in the experiments of Section 5.2. This matters because Eq. (8) can be rewritten as ss = α·td + (1−α)·t_ct + β·lf; the preference between earlier and later completion times reverses at α = 1, so the direction of the selection behavior is unknown without the exact value. Please report the chosen α and β and include a sensitivity analysis to demonstrate that the claimed 13% and 3.88% TCR improvements are not artifacts of a single hand-picked configuration.","section":"Section 5.1 and Section 5.2"},{"comment":"The parameter k in 'Select the top k PUs with the smallest absolute difference' is never defined in Algorithm 2 or in the accompanying text. Moreover, Line 12 randomly chooses one PU from the top k, introducing nondeterminism without any repeated-run statistics. This makes the PORA component and its contribution to the reported TCR irreproducible; please define k, justify its value, and report results averaged over multiple random choices.","section":"Algorithm 2, Line 11"},{"comment":"All TCR comparisons appear to be based on a single simulation run. Since tasks are randomly generated (Section 5.1) and PORA includes random selection (Algorithm 2, Line 12), the reported differences (1.37%, 1.5%, 3.88%, and 13%) lack error bars, confidence intervals, or any statistical significance test. Please provide mean and variance over multiple independent random seeds and state whether the observed differences are significant.","section":"Section 5.2"}],"minor_comments":[{"comment":"The notation around Eq. (1) is inconsistent: the text says bwej,k and bweB,u are bandwidths, but later refers to 'bweB,u is the distance between B and ecu.' Please clarify which symbols denote distances and which denote bandwidths, and verify the units of Eq. (1).","section":"Section 3.2, Eq. (1)"},{"comment":"The deadline ranges in Table 1 (e.g., [1,10] for group 1) are difficult to interpret alongside the text that says deadlines are calculated as the release time plus workload plus a random number; please clarify what the table entries represent.","section":"Section 5.1, Table 1"},{"comment":"The captions of Figs. 2 and 3 do not specify the TSP algorithm used for the comparison or the parameter values of α and β; please add this information to make the figures interpretable.","section":"Figures 2 and 3"},{"comment":"The title of reference [16] contains 'A VE' which appears to be a typographical error for 'AVE' or 'A-VE'; please correct it.","section":"Reference [16]"}],"recommendation":"major_revision","confidential_remarks":"This is a short conference-style paper (CSCI 2024) and the evaluation is far too thin for a journal submission. The most serious issue is the sign of the load-factor term in Eq. (8), which, if taken literally, invalidates the load-balancing narrative and makes the algorithm unreproducible. The missing parameter values (α, β, PORA top-k) and the absence of any statistical validation are additional blockers. The algorithmic idea may be salvageable with a corrected formula, exact parameter reporting, and a sensitivity/multi-run analysis, but as it stands the numeric claims should not be accepted. I would not recommend reject outright because the problems are fixable in principle, but the required revisions are substantial."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This paper proposes a suitability-based resource selection algorithm (SARS) plus a standby-resource mechanism (PORA) for heterogeneous mobile edge computing, and reports up to 13% TCR gains over classical RSP baselines. The algorithms are clearly described and the combination is genuinely new for this subfield. The comparison against six TSP algorithms and several RSP baselines is more thorough than most papers in this niche, and the simulation setup is detailed enough to reimplement. The related-work coverage is relevant and current, with no citation red flags.\n\nThe soft spots are load-bearing, though. First, Eq. (8) defines the suitability score as t_ct + alpha*tm + beta*lf. Since tm = deadline - t_ct, for a fixed deadline this reduces to alpha*deadline + (1-alpha)*t_ct + beta*lf. The load factor lf is current load divided by max load, and the algorithm selects the PU with the highest score. So a positive beta makes high-load PUs more attractive, directly contradicting Section 4.1's claim that the load factor 'ensures that highly utilized PUs are less likely to be allocated to additional tasks.' If the implementation actually subtracts beta*lf, the text is wrong; if it follows Eq. (8), the stated balancing mechanism is not what drives the reported improvement. Either way, the paper as written is internally inconsistent on its central mechanism.\n\nSecond, alpha and beta were tuned by trial-and-error on the same simulation used for the reported numbers (Section 5.1), and the actual alpha value is not reported. That makes the 13% claim a fitted result, not a predictive one, and it is not reproducible. Third, the PORA top-k parameter is never defined, so that algorithm is also under-specified. Fourth, Eq. (1) multiplies (file size / bandwidth) by distance, which is dimensionally wrong; the simulation likely did not actually compute delays this way, but as written the model is incoherent.\n\nThe central idea that a suitability score can improve RSP is plausible, and the paper is worth reading as a design note. But the current evidence does not support the numeric claim as stated, and the internal contradiction in Eq. (8) means the published algorithm cannot be reproduced as described.\n\nFor peer review: this deserves a serious referee. The algorithms are clear and the internal contradiction is exactly the kind of thing a careful review should catch. I would send it to a workshop or short-paper venue with a request for major revision, not desk-reject it.","headline":"A clear but unreproducible RSP heuristic: the load-factor term in Eq. (8) has the wrong sign for load balancing, and the headline 13% gain comes from same-simulation parameter tuning.","tokens_in":12603,"tokens_out":3076,"would_cite":false,"duration_ms":27834,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A suitability-based resource selection algorithm with reserved processing units can push task completion rates up to 13 percent higher than classical edge-server selection in simulated autonomous driving offload.","keywords":["autonomous driving","mobile edge computing","resource allocation","real-time task scheduling","task offloading","task completion rate","suitability score","edge server heterogeneity"],"falsifier":"Run the same 800-task simulation with fresh random draws of release times, workloads, file sizes, distances, and bandwidths, keeping $\\alpha$ and $\\beta$ fixed at the values from Section 5.1, and compare the TCR of SARS+PORA against the shortest-execution-time and latest-PU baselines; the central claim fails if the 13% and 3.88% margins are not reproduced. A sharper version is to replace the four task groups with a bimodal deadline distribution and check whether reserving average-rate PUs still helps.","tokens_in":11534,"feed_emoji":"🚗","tokens_out":6079,"duration_ms":55493,"temperature":0.7,"pith_summary":"Offloading real-time tasks from autonomous vehicles to edge servers requires two decisions: which task to run next and which server to run it on. This paper argues that existing work has focused on the first decision and relied on crude rules, such as shortest execution time, random choice, or latest feasible finish, for the second. It proposes a suitability-based adaptive resource selection (SARS) algorithm that scores every processing unit (PU) by a weighted combination of estimated completion time, time margin before the task's deadline, and current load, then picks the highest-scoring PU that can still meet the deadline. A companion proactive on-demand resource allocation (PORA) algorithm reserves one PU per edge server near the server's average processing rate and releases it only when no ordinary PU can meet an urgent task's deadline. In simulation, the two together raise the task completion rate by up to 13% over the shortest-execution-time rule and by 3.88% over the best classical rule, across every task-selection policy tested.","feed_headline":"Reserved edge PUs lift task completion by up to 13%","feed_subtitle":"A weighted time-margin plus load score beats shortest execution time for autonomous-driving offload.","key_machinery":"The load-bearing object is the suitability score $ss = t^{ct} + \\alpha \\cdot tm + \\beta \\cdot lf$, where $t^{ct}$ is the estimated completion time on a given PU, $tm$ is the time margin (deadline minus estimated completion time), and $lf$ is the load factor (the PU's current load divided by the maximum load among all PUs). SARS evaluates every PU in every edge server for each task, keeps only PUs whose predicted completion leaves a non-negative time margin, and chooses the one maximizing $ss$. PORA runs once per server: it computes the average processing rate of the server's PUs, finds the PU closest to that average, and puts it in standby; when SARS finds no feasible PU, PORA releases that reserved PU for the urgent task and later returns it to standby. This two-stage mechanism is what carries the empirical advantage.","core_discovery":"The central claim is that how tasks are assigned to processing units determines how many deadline-constrained tasks finish, independent of which task-selection policy is used. For every task-selection policy tested (FCFS, EDF, EDD, EFDF, CR, COVERT, and two priority-based policies), replacing the classical resource-selection rule with SARS raises the task completion rate. On its own SARS improves the best classical rule by 1.37% in the CR policy and 1.5% in EDF; when PORA is enabled, the integrated system finishes 3.88% more tasks than the latest-feasible-PU rule and 13% more than the shortest-execution-time rule in the tested scenario. The paper therefore concludes that a suitability-based RSP plus proactive reservation is a practical way to prioritize urgent tasks and increase throughput in a heterogeneous MEC architecture.","pith_inferences":["The paper does not provide a proof of optimality or a bound; the claim is empirical on one 800-task scenario, so transferability to larger fleets, multiple brokers, or different task distributions is untested.","The choice to reserve the PU whose processing rate is closest to the server average is heuristic; a natural test is whether reserving the fastest or slowest PU changes the task completion rate.","If the weights $\\alpha$ and $\\beta$ must be retuned per scenario, the practical value depends on finding a calibration rule; the paper's own suggestion of learning these weights could be tested directly.","The suitability-score form is a linear combination of completion time, time margin, and normalized load; other weighting schemes or normalizations could be compared without changing the architecture."],"forward_implications":["Any task-selection policy (EDF, FCFS, CR, COVERT, and priority-based policies) sees a higher task completion rate when its resource-selection step is swapped to SARS, so the gain is not tied to one scheduling policy.","The largest reported gains require the reserved-PU mechanism: SARS with PORA beats the best classical RSP by 3.88%, while SARS alone beats it by only 1.37 to 1.5%.","The reserve strategy helps urgent tasks specifically, because a PU is held back precisely for tasks that no available PU can meet within their time interval.","SARS does not require changing task prioritization; it can be dropped into existing MEC brokers that already run EDF or other task-selection policies."],"supporting_citations":[{"why":"Supplies the shortest-execution-time RSP baseline that SARS must beat.","marker":"[6]"},{"why":"Supplies the random-selection RSP baseline and the classical EDF scheduling basis used in the comparison.","marker":"[8]"},{"why":"Supplies the latest-feasible-PU RSP baseline, the strongest non-SARS competitor in the experiments.","marker":"[11]"},{"why":"Supplies the priority-based ERA scheduling algorithm whose RSP is swapped to SARS in the comparison.","marker":"[17]"},{"why":"Supplies the priority queuing model baseline used to show SARS improves priority-based schedulers.","marker":"[18]"}],"fun_headline_variants":["Suitability-based edge selection lifts urgent task throughput","Edge server selection algorithm boosts task completion by 13%","Proactive edge resource reservation ups task completion 13%","Adaptive edge selection prioritizes critical tasks, boosts throughput"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The reported advantage depends on two tuning dials ($\\alpha$ and $\\beta$) being set by trial and error on the exact same simulation that is later used to measure the advantage; if those dials have to be reset whenever the tasks or servers change, the 13% gain will not carry over.","fun_headline_variants_meta":{"raw":{"variants":["Suitability-based edge selection lifts urgent task throughput","Edge server selection algorithm boosts task completion by 13%","Proactive edge resource reservation ups task completion 13%","Adaptive edge selection prioritizes critical tasks, boosts throughput"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000203,"raw_usage":{"total_tokens":1390,"prompt_tokens":951,"completion_tokens":439,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":567,"completion_tokens_details":{"reasoning_tokens":373}},"tokens_in":567,"tokens_out":439,"duration_ms":4059,"temperature":1.0,"reasoning_tokens":373,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T13:38:28.279868+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same 800-task simulation with fresh random draws of release times, workloads, file sizes, distances, and bandwidths, keeping $\\alpha$ and $\\beta$ fixed at the values from Section 5.1, and compare the TCR of SARS+PORA against the shortest-execution-time and latest-PU baselines; the central claim fails if the 13% and 3.88% margins are not reproduced. A sharper version is to replace the four task groups with a bimodal deadline distribution and check whether reserving average-rate PUs still helps.","supporting_citations":[{"cited_title":"IEEE Journal on Selected Areas in Communications 37(5), 1159–1166 (2019)","cited_arxiv_id":null,"evidence_quote":"Supplies the shortest-execution-time RSP baseline that SARS must beat."},{"cited_title":"Springer Science & Bus iness Media, Vol","cited_arxiv_id":null,"evidence_quote":"Supplies the random-selection RSP baseline and the classical EDF scheduling basis used in the comparison."},{"cited_title":"Journal of Network and Computer Applications 204, Article 103333 (2022)","cited_arxiv_id":null,"evidence_quote":"Supplies the latest-feasible-PU RSP baseline, the strongest non-SARS competitor in the experiments."},{"cited_title":"In: Pro- ceedings of the ACMSE 2018 Conference, pp","cited_arxiv_id":null,"evidence_quote":"Supplies the priority-based ERA scheduling algorithm whose RSP is swapped to SARS in the comparison."},{"cited_title":"Computer Communi cations 172, 75–83 (2021)","cited_arxiv_id":null,"evidence_quote":"Supplies the priority queuing model baseline used to show SARS improves priority-based schedulers."}],"review_version":1}