PaperlayerView exact revision on arXiv

Source-linked AI summary

HLSR: Hybrid Live Forecast Selective Dynamic Vehicle Rerouting for Real-Time Congestion Avoidance

Xiao Wang, Shun Ren Yang, Hui Nien Hung

arXiv:2608.18056v1cs.AI

TL;DR

Urban congestion mitigation needs rerouting beyond current live traffic while avoiding network-wide replanning of nearly all vehicles. HLSR selectively combines live speeds with short-horizon forecasts and reduces mean travel time from 664.2 s to 438.1 s at 8000 vehicles.

  • Problem

    Existing rerouting methods have recurring limitations in detecting heterogeneous congestion, selecting approaching vehicles, and incorporating forecasts for later-traversed segments.

  • Method

    HLSR selectively reroutes congestion-affected vehicles using dual-threshold detection, calibrated upstream expansion, weighted k-shortest paths, and horizon-adaptive live–forecast costing.

  • Results

    438.1 s versus 664.2 s (BC) at 8000 vehicles, while HLSR outperforms competing baselines across evaluated demand levels.

  • Takeaways & Limitations

    Hybrid live–forecast costing is the primary performance driver, while the prediction backbone provides secondary support within the selective rerouting framework.

Abstract

from arXiv · show

Urban traffic congestion reduces productivity and increases travel cost and emissions. Network-wide live travel-time shortest-path rerouting can be highly effective in simulation, but assumes that essentially every on-road vehicle is replanned every decision period. We propose HLSR, a selective hybrid live--forecast vehicle rerouting framework that fuses live edge speeds with short-horizon forecasts under limited intervention scope. Building on dual-threshold congestion detection, calibrated upstream selection, and driver-tailored travel-time prediction, HLSR further introduces approaching-vehicle expansion, travel-time-weighted k-shortest-path generation, and a horizon-dependent hybrid live--forecast segment speed used in multi-cost route allocation.

I. INTRODUCTION … B. Platform Architecture and Sensing

HLSR addresses congestion through selective, proactive rerouting that combines dual-threshold detection, calibrated vehicle selection, and hybrid live–forecast route costing. The paper defines its network, sensing architecture, and evaluation scope around this integrated framework.

  • I. INTRODUCTION: Urban growth increases traffic pressure, while infrastructure-only navigation may fail to replan en-route vehicles and can funnel demand onto insufficient-capacity links.Intelligent transportation systems therefore combine connected sensing, edge/cloud computing, and data-driven control for real-time congestion mitigation.
  • I. INTRODUCTION: HLSR retains congestion detection, rerouted-vehicle selection, and alternative-route allocation while limiting replanning to congestion-related vehicles.Its hybrid live–forecast costing preserves responsiveness to observed speeds during near-term decisions.
  • I. INTRODUCTION: 438.1 s (HLSR-LIVE) versus 664.2 s (BC) is achieved at 8000 vehicles using dual-threshold detection, calibrated upstream hop depth, and approaching-vehicle expansion.These mechanisms bound intervention while targeting vehicles related to congestion.
  • I. INTRODUCTION: 380.6 s (HLSR) versus 438.1 s (HLSR-LIVE) results from horizon-dependent live–forecast costing, travel-time-weighted k-shortest paths, and multi-cost allocation.The comparison uses a matched selective candidate scope.
  • II. RELATED WORK: Prior work commonly addresses detection, vehicle selection, or route allocation separately, leaving limited integration of dual thresholds, calibrated upstream selection, approaching-vehicle expansion, and hybrid live–forecast allocation.Existing allocation methods primarily rely on present traffic conditions rather than explicitly fusing short-horizon forecasts with live sensing.
  • A. Road Network and Zone Partition: The system models a directed urban road network partitioned into city zones, with segments characterized by length, lane count, and speed limit.Vehicles report locations and destinations, and the candidate-route budget defaults to Ncr=7; arrivals and destinations are exogenous to the selective controller.
  • B. Platform Architecture and Sensing: The platform uses a cloud-hosted centralized controller that integrates roadside sensing, vehicle reports, and periodic detector exports into a consistent network view.Roadside units collect vehicle locations and destinations, while CCTV and velocity / loop detectors export per-segment occupancy and mean-speed traces.
  • B. Platform Architecture and Sensing: Vehicle reports maintain Nv(s, τ) and support route updates, while detector exports supervise prediction and provide live edge speeds for hybrid costing.These sensing quantities are maintained at each decision instant.

C. Occupancy and Velocity Observables … 2) Driver-tailored segment average velocity:

HLSR builds route-cost inputs from windowed occupancy and speed observables, multi-horizon network forecasts, and driver-tailored predicted velocities. It blends live sensing with forecasts for hybrid travel-time costing while keeping selective vehicle selection separate.

  • C. Occupancy and Velocity Observables: Occupancy and speed statistics are accumulated over default T=300 s windows, whose boundaries invoke selective control and provide congestion-state indicators RO and RV.These indicators support threshold-based congestion detection.
  • D. Live and Predicted Speed Values: Live segment speed V live(s, τ) comes from current mean-speed sensing through TraCI or detectors.The live value is available at each decision time for candidate-route costing.
  • D. Live and Predicted Speed Values: Predicted speeds V pred(s, τ, h) span horizons h=1, . . . , Tout, with near-term segments weighted toward live sensing and farther segments toward forecasts.HLSR does not use predicted speeds as a stand-alone rerouter.
  • E. Travel-Time Components: Segment travel time decomposes into traffic-light queueing delay tq and road-segment passing time tp, with passing time based on hybrid speed and optional driver-tailored correction.The blended speeds are embedded in multi-cost route allocation.
  • IV. TRAVEL TIME PREDICTION: The prediction module supplies multi-horizon V pred(s, τ, h) for hybrid live–forecast route costing, while selective vehicle selection remains separate.It adopts the previously published spatio-temporal forecaster LSTAN_GERPE.
  • A. Forecasting Design: Forecasting is evaluated at route level because edge-level errors can preserve RMSE yet still invert candidate-path rankings.HLSR scores full candidate routes rather than isolated sensors.
  • 1) Network-level speed-value prediction:: LSTAN_GERPE consumes short histories of network-wide mean speed and occupancy and emits multi-horizon predicted speeds for every segment.GERPE pattern keys capture daily recurring patterns without fitting a separate model per edge.
  • 2) Driver-tailored segment average velocity:: A driver-behavior model maps each network-level segment prediction into vehicle-specific average velocity VA(·) using Bd(vr, s) and calibrated factor ∆.The personalized speed feeds the forecast branch of hybrid costing and does not replace live sensing for near-horizon segments.

B. The Prediction Framework · C. Network-Level Spatio-Temporal Forecaster · 1) Network-Wide Speed-Value Formulation:

HLSR iteratively predicts vehicle-specific segment travel times by combining traffic-light delay, forecasted network speeds, and driver-tailored velocity estimates. Its forecaster uses detector histories and graph structure to produce shared multi-horizon network-wide speeds, which are adaptively fused with live observations during routing.

  • B. The Prediction Framework: The framework iteratively predicts each candidate-route segment’s travel time and the vehicle’s entering time into the next segment.The current route entering time initializes the process, and each iteration supplies the next segment’s entering time.
  • B. The Prediction Framework: Traffic-light queueing time captures remaining red-light delay and transient residence after the signal turns green.The estimates use predefined signal timing plans and a probabilistic model.
  • B. The Prediction Framework: Road-segment passing time begins when the vehicle leaves the entrance traffic light and starts crossing the segment.The framework uses the segment-entry time adjusted by traffic-light queueing time as the crossing start instant.
  • B. The Prediction Framework: The driver-tailored model converts network-forecast speed into the vehicle’s average velocity using behavior parameter Bd.The network-level forecaster first supplies the segment speed before this vehicle-specific mapping.
  • C. Network-Level Spatio-Temporal Forecaster: The forecasting module uses loop-detector measurements arranged over road-segment nodes in the directed graph.S denotes the road-segment set and N = |S| its cardinality; measurements at decision instant τ construct the historical input tensor.
  • 1) Network-Wide Speed-Value Formulation:: The model receives Tin = 12 one-minute steps with F = 2 features—mean speed and occupancy—and projects them to multi-horizon segment-speed predictions.The formulation also uses graph-derived Laplacian positional encoding, while Tout = 6 sets the prediction horizon length.
  • 1) Network-Wide Speed-Value Formulation:: During route assignment, predicted speeds are fused with live observations by horizon: near-future segments emphasize sensors, while farther segments emphasize predictions.A single forward pass produces globally consistent network-wide estimates shared across candidate routing alternatives, unlike independent per-edge sequential predictors.

2) LSTAN-GERPE Architecture: … 1) Assumption and definition:

The paper combines the LSTAN_GERPE graph-aware multi-horizon forecaster with optional route-ranking fine-tuning, while defining driver-tailored segment velocities from vehicle histories, behavior normalization, and calibrated distribution mapping.

  • 2) LSTAN-GERPE Architecture:: LSTAN_GERPE supplies HLSR’s speed predictions through graph-aware encoding, rotary positional encoding, spatio-temporal attention, and a multi-horizon decoder.Its Huber loss and hyperparameters are inherited from prior work rather than introduced as novel contributions.
  • 3) Reroute-Aligned Fine-Tuning:: Route-ranking fine-tuning addresses cases where acceptable edge-level regression still reverses complete-path travel-time ordering.The pretrained encoder remains frozen while an OD-based k-shortest-path ranking loss adapts the prediction head.
  • 3) Reroute-Aligned Fine-Tuning:: The ranking loss compares predicted and ground-truth travel times for filtered path pairs within each OD’s K = Ncr loop-free candidate paths.Pairs with ground-truth time differences below tmin are excluded, and the logistic penalty increases with ranking inversion.
  • 3) Reroute-Aligned Fine-Tuning:: Because comparisons are restricted to same-OD k-shortest candidates, Lod ksp directly regularizes the path-discrimination task used by route allocation.Closed-loop fine-tuning redeploys updated forecasts in the selective rerouting simulator and uses resulting traffic measurements for subsequent ranking updates.
  • 1) Assumption and definition:: Single-vehicle average velocity is computed from segment length divided by the vehicle’s measured exit-entry time, using monitoring velocity and historical traffic information.The formulation assumes access to each vehicle’s velocity, entry time, and exit time.
  • D. Driver-Tailored Segment Average Velocity: Driver behavior is represented by Bd(vr, s), obtained by Min-Max normalization between the maximum- and minimum-history vehicle velocities on a segment.The driver-tailored factor ∆ is correlated with Bd(vr, s), while network-level predicted or live speed is related to individual vehicle average velocity.
  • 1) Assumption and definition:: ∆ calibration uses detector and vehicle velocity data, selects fifty vehicles per segment, and estimates a power-based parametric CDF by maximum likelihood.The method improves prediction efficiency through linear transformation and reports better performance when ns is sufficiently large; empirical agreement is verified experimentally.
  • D. Driver-Tailored Segment Average Velocity: The calibrated mapping transforms (Bd)ηs into the observed CDF range using zmin and zmax, then relates predicted individual velocity to network-level segment speed.Calibration uses zs samples and verifies agreement between F(z) and F(∆) with calibrated (zmin, zmax, η) values.

3) Time Cost Calculation:

Algorithm 1 calculates each candidate route’s travel-time cost by accumulating segment times from forecasted speeds. For every route segment, it adds the segment length divided by the forecaster’s predicted speed, using the driver factor Δ.

  • Time Cost Calculation: Algorithm 1 accumulates travel time for candidate route r_k(v_r, τ) using predicted segment speeds and driver factor Δ.The forecaster provides V^pred_k(v_r, τ) for each route segment.
  • Time Cost Calculation: For each segment, the route cost adds segment length L_rs divided by predicted speed V̂.This per-segment accumulation produces the route time cost C_V.
  • Time Cost Calculation: The procedure computes network-wide predicted speeds from forecaster f_θ and history tensor X_τ before iterating over route segments.The loop processes segments j from 1 through the route length.

V. THE PROPOSED HLSR FRAMEWORK … B. Phase 2: Rerouted Vehicle Selection

HLSR performs selective real-time rerouting through a three-phase pipeline: congestion detection, rerouted-vehicle selection, and route allocation. Its detection module uses dual traffic thresholds to identify congestion and return both a binary status and severity measure.

  • V. THE PROPOSED HLSR FRAMEWORK: HLSR replans only vehicles impacted by congestion rather than recalculating paths for all vehicles each cycle.The framework organizes rerouting into congestion detection, vehicle selection, and route allocation before assembling the runtime loop.
  • V. THE PROPOSED HLSR FRAMEWORK: Roadside sensing data feeds the rerouting workflow and forecasting module, while Phase 3 combines live and predicted speeds for candidate-path costs.
  • A. Phase 1: Traffic Congestion Detection: Algorithm 2 structures congestion detection into input specification, output definition, variable initialization, and execution procedure.
  • 1) Input Parameters:: The detection function requires a target road segment, decision timestamp, occupancy threshold, velocity threshold, and occupancy-indicator weight.
  • 2) Output Results:: Detection returns isCongested, a binary congestion flag, and RS(s, τ), a continuous congestion severity metric.
  • 3) Initialization Stage:: Before computation, isCongested is initialized to False and RS(s, τ) to 0.
  • 4) Execution Procedure:: Congestion is triggered only when normalized occupancy and reduced normalized velocity both exceed their respective thresholds; the module then sets isCongested to True and computes RS(s, τ).The function returns the flag and severity value, and congested segments at decision time τ form the congested set.
  • B. Phase 2: Rerouted Vehicle Selection: Phase 2 screens vehicles for rerouting through the RVS function summarized in Algorithm 3.The screening logic is described through its inputs, outputs, and computational workflow.

1) Input Parameters: · 2) Output Results: · 3) Execution Procedure:

The selection module takes a congested target segment, decision timestamp, and upstream hop depth, then produces vehicles assigned for rerouting. It builds this set from upstream traffic layers and approaching vehicles, with θur=9 recommended to balance intervention range and over-rerouting risk.

  • 1) Input Parameters:: The selection module requires congested target segment sc, current decision timestamp τ, and upstream hop depth θur.These three inputs define the congestion context, timing, and upstream selection range.
  • 2) Output Results:: The module outputs vehicle set STThe output is completed as ST rv(sc, τ), collecting vehicles assigned to rerouting for congestion mitigation on sc.
  • 2) Output Results:: The congestion-detection procedure uses segment s, timestamp τ, occupancy and velocity thresholds, and occupancy weight Ψro to return isCongested and RS(s, τ).The procedure computes occupancy ratio, updates RS(s, τ), and returns the congestion flag with its score.
  • 3) Execution Procedure:: A larger θur expands the intervention range but increases over-rerouting risk; the recommended deployment uses θur=9.θur denotes the maximum upstream layer considered for vehicle selection.
  • 3) Execution Procedure:: The base intervention set includes vehicles currently located on upstream segments within the topology window.This set is supplemented by vehicles outside the window when they are approaching sc along planned routes.
  • 3) Execution Procedure:: Approaching vehicles are added when sc remains on their pre-planned route and lies within at most two remaining route hops.The final rerouting set unions upstream vehicles with these approaching vehicles; duplicate vehicles retain the smaller hop index for later sorting.

C. Phase 3: Alternative Route Allocation · 1) Input Parameters: · 2) Execution Procedure:

Phase 3’s ARA module allocates alternative routes for selected vehicles using horizon-adaptive live–forecast speeds, travel-time-weighted candidate generation, and normalized multi-objective minimization. It processes vehicles in a calibrated order and updates occupancy after each assignment so later route choices reflect diverted flows.

  • 1) Input Parameters:: ARA requires the decision timestamp τ, aggregated rerouting vehicle set ST_rv(sc, τ), and per-vehicle candidate-path limit Ncr.
  • 2) Execution Procedure:: For each vehicle in ST_rv(τ), ARA generates Ncr feasible candidate paths and selects an optimal route through multi-objective cost minimization.
  • 2) Execution Procedure:: The fused segment speed blends detector-based live speed V live(s, τ) with personalized forecast speed V pred(s, τ, h), favoring live data near-term and forecasts farther ahead.The live-data weight α(h) decays linearly and becomes zero when h ≥⌈α0/α∆⌉, making the fused speed fully forecast-based.
  • 2) Execution Procedure:: The horizon index h measures complete aggregation windows until estimated segment entry, so the same segment can receive different live–forecast weights for different vehicles.Early segments therefore use live-dominant speeds, whereas downstream segments use forecast-heavy speeds.
  • 2) Execution Procedure:: Vehicles are sorted by ascending upstream hop index and descending residual destination distance, prioritizing bottleneck-near vehicles with longer remaining trips.
  • 2) Execution Procedure:: Yen’s K-shortest path algorithm uses fused-speed travel-time edge weights at h=0, placing fast, low-congestion corridors into the candidate pool before final ranking.
  • 2) Execution Procedure:: ARA jointly minimizes normalized travel time Ctt, path length Cd, route similarity penalty Cs, and occupancy balance Co, with recommended weights (wt, wd, ws, wo) = (0.45, 0.20, 0.15, 0.20).Each metric is min–max normalized over the vehicle’s candidate set before weighted minimization.
  • 2) Execution Procedure:: Vehicles are rerouted sequentially, with predicted road-occupancy footprints updated after each assignment before route instructions are issued.Optional traffic-light waiting delay can be included in the route cost.

D. Main Runtime Loop

HLSR operates as a centralized cloud–SUMO co-simulation that continuously aggregates live segment data and executes selective rerouting at fixed aggregation-window boundaries. At each boundary, it detects congested segments, selects affected vehicles, and performs one-shot hybrid live–forecast route assignment.

  • Runtime architecture: The centralized platform co-simulates with SUMO through TraCI while continuously aggregating roadside segment speed and occupancy measurements.These measurements support window-level traffic processing and selective rerouting.
  • Selective rerouting: When C(τ) ≠ ∅, the runtime loop unions per-bottleneck vehicle sets, including upstream and approaching vehicles, before route assignment.This corresponds to Phase 2 of the main loop.
  • Route assignment: Phase 3 assigns hybrid live–forecast routes in one shot using V pred from Sec. IV.The loop continues step-by-step while unfinished trips remain in SUMO.
  • Window processing: During each fixed-length window, HLSR aggregates traffic statistics across all segments and scans every s ∈S for congestion.Detection is performed when simulation time reaches a boundary τ = nT.

VI. PERFORMANCE EVALUATION … 3) Travel-Time Prediction Setup:

The evaluation tests HLSR through component and forecaster ablations and comparisons across multiple demand scales, using a calibrated Tainan SUMO testbed. It also specifies the upstream-depth operating point and the live-data, forecasting, and driver-behavior setup underlying route-cost prediction.

  • VI. PERFORMANCE EVALUATION: HLSR is evaluated through component and forecaster ablations in the 8000-vehicle Tainan scenario, followed by comparisons with competing rerouting methods at three demand scales.The evaluated scales are 8000, 16000, and 20000 vehicles.
  • 1) Simulation Platform and Road Network:: The testbed contains 204 intersections, 561 road segments, 77.3 km of roadway, and 14 traffic-analysis zones in Tainan’s West Central District.The network is imported from OpenStreetMap and preprocessed with Netconvert; five zones are origins and four are destinations.
  • 1) Simulation Platform and Road Network:: 25% of vehicles are released in each of four successive 1800 s intervals within a 7200 s simulation window, and trials continue until all trips finish.The evaluated demand scales are 8000, 16000, and 20000 vehicles on the fixed topology.
  • 2) Evaluation Parameters:: The experiments use SUMO seed 42, T=300 s aggregation, Ncr=7 candidate routes, dual-threshold detection, hybrid blending, multi-cost weights, and two-hop approaching expansion.The recommended configuration uses (δO, δV )=(0.55, 0.45) and (α0, α∆)=(0.75, 0.12).
  • 2) Evaluation Parameters:: 380.6 s is the minimum mean travel time in the θur sweep at 8000 vehicles, achieved at θur=9; θur=10 is essentially tied at 380.8 s.Mean travel time is nearly flat for θur ∈ [3, 8], while reroutes per vehicle increase almost monotonically; θur=11 rises to 388.0 s.
  • 3) Travel-Time Prediction Setup:: Per-minute loop-detector speed and occupancy measurements form Xτ and drive closed-loop fine-tuning of the ranking-enhanced LSTAN GERPE forecaster, whose V pred outputs feed hybrid costs.The detectors are deployed across the Tainan road network.
  • 3) Travel-Time Prediction Setup:: The forecasting backbone is pre-trained, then fine-tuned by freezing encoder weights and optimizing only the prediction head with an OD-aware k-shortest-path ranking loss.The settings include λrank=0.015, tmin=10 s, mini-batches of eight OD pairs, up to 32 candidate paths per OD pair, and learning rate 5×10−5.
  • 3) Travel-Time Prediction Setup:: Driver-behavior parameters are calibrated from SUMO and Taipei detector traces, and CDF comparisons validate the adopted power-law formulation for the driver-tailored factor ∆.Civic Street and Xinyi Street show fitting performance consistent with the representative Nanjing Road comparison.

B. Ablation Study … VII. CONCLUSION

The ablation and baseline studies show that HLSR’s hybrid live–forecast costing is its largest contributor to travel-time improvement, while ranking-aware forecasting and selective intervention support robust performance across demand levels. The conclusion identifies HLSR’s integrated modules and confirms lower travel times than live-only and network-wide alternatives with fewer rerouted vehicles.

  • 1) HLSR Component Ablation:: At 8000 vehicles, disabling hybrid live–forecast costing produces the largest ablation penalty, +57.5 s, with the candidate vehicle set fixed.The gap is attributed to Phase-3 speed fusion rather than upstream vehicle selection.
  • C. Baseline Routing Comparison: At 8000 vehicles, HLSR reaches 380.6 s, beating HLSR-LIVE at 438.1 s by 57.5 s and CAIE-TT-Scoped at 391.6 s by 11.0 s.Network-wide CAIE-TT remains slower at 408.1 s despite replanning more vehicles.
  • C. Baseline Routing Comparison: HLSR remains best as demand rises, with mean travel times of 895.7 s and 971.7 s at 16000 and 20000 vehicles.At these demands, HLSR-LIVE reaches 1281.3 s and 1410.0 s, while network-wide CAIE-TT reaches 1013.9 s and 1180.0 s.
  • D. Discussion: Baseline gaps widen under heavy congestion: CAIE-TT-Scoped trails HLSR by 115.9 s and 148.6 s, while Du-GAQ degrades to 1384.4 s and 1463.1 s.Du-GAQ was competitive at 8000 vehicles but does not scale well to higher-demand cases.
  • 1) HLSR Component Ablation:: Under hybrid costing, time-only scoring (+25.0 s), occupancy-only detection (+19.7 s), disabled driver personalization (+12.4 s), and θur=4 (+5.1 s) cause progressively smaller penalties.These differences are relative to recommended HLSR with θur=9 and Rank forecasting.
  • 2) Forecaster Comparison:: Ranking-aware forecasting is preferred: HLSR-LSTM incurs +7.6 s and HLSR-Huber +20.2 s, both below the HLSR-LIVE penalty.The recommended HLSR adds OD-aware k-shortest-path ranking loss to the same network-level backbone used by HLSR-Huber.
  • VII. CONCLUSION: On the reproduced Tainan SUMO testbed, HLSR lowers mean travel time versus fair-scope live-only baselines and network-wide live Dijkstra while rerouting considerably fewer vehicles.The conclusion attributes the major improvement to hybrid live–forecast costing and a secondary supporting role to the prediction backbone.
  • VII. CONCLUSION: HLSR combines dual-threshold congestion detection, calibrated upstream depth with approaching-vehicle expansion, travel-time-weighted k-shortest paths, and horizon-adaptive hybrid costing.Its network-level forecaster supplies predicted speeds for hybrid costs rather than serving as an end-to-end rerouting solution.

APPENDIX · A. Notation List

Appendix A presents Table IV as the paper’s notation list, with the table continued across multiple passages. The table is marked as an editing reference intended for removal before submission.

  • A. Notation List: Appendix A contains Table IV, titled “Notations.”
  • A. Notation List: The notation table is identified as an editing reference.
  • A. Notation List: The table carries an instruction to remove it before submission.
  • A. Notation List: The notation list spans three presented table passages.
  • A. Notation List: Table IV continues in a subsequent passage.
  • A. Notation List: The continuation retains the editing-reference designation.
  • A. Notation List: The continued table again states that it should be removed before submission.
  • A. Notation List: A further passage continues Table IV’s notation list.
Loading 2608.18056v1…