Paper deep dive
HLSR: Hybrid Live Forecast Selective Dynamic Vehicle Rerouting for Real-Time Congestion Avoidance
Xiao Wang, Shun Ren Yang, Hui Nien Hung
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 8/22/2026, 1:58:59 AM
Summary
The paper proposes HLSR, a selective hybrid live-forecast vehicle rerouting framework designed to mitigate urban traffic congestion. Unlike network-wide rerouting, HLSR intervenes on a limited scope of vehicles using dual-threshold congestion detection, calibrated upstream selection, and driver-tailored travel-time prediction. It fuses live edge speeds with short-horizon forecasts (using the LSTAN_GERPE model) for route costing, demonstrating superior performance in reducing mean travel time compared to live-only and network-wide baselines in SUMO simulations.
Entities (10)
Relation Signals (8)
HLSR → outperforms → live-only controls
confidence 95% · HLSR reduces mean travel time to 380.6 s ... outperforming same-scope live-only controls (438.1 s selective live)
HLSR → uses → LSTAN_GERPE
confidence 95% · A network-level spatial–temporal forecaster (LSTAN_GERPE, optionally ranking-fine-tuned) supplies the forecast branch of the hybrid cost
Shun-Ren Yang → affiliatedwith → National Tsing Hua University
confidence 90% · X. Wang and S.-R. Yang are with the Department of Computer Science and the Institute of Communications Engineering, National Tsing Hua University
Xiao Wang → affiliatedwith → National Tsing Hua University
confidence 90% · X. Wang and S.-R. Yang are with the Department of Computer Science and the Institute of Communications Engineering, National Tsing Hua University
Hui-Nien Hung → affiliatedwith → National Chiao Tung University
confidence 90% · H. Hung is with the Institute of Statistics, National Chiao Tung University
HLSR → appliedin → Tainan
confidence 90% · On a reproduced Tainan SUMO scenario
HLSR → evaluatedon → SUMO
confidence 90% · On a reproduced Tainan SUMO scenario (seed 42), HLSR reduces mean travel time
HLSR → usescomponent →
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract: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.
Tags
Links
- Source: https://arxiv.org/abs/2608.18056v1
- Canonical: https://arxiv.org/abs/2608.18056v1
Trouble viewing inline? Open PDF directly →
Full Text
80,189 characters extracted from source content.
Expand or collapse full text
HLSR: Hybrid Live–Forecast Selective Dynamic Vehicle Rerouting for Real-Time Congestion Avoidance Xiao Wang Shun-Ren Yang Hui-Nien Hung Thanks: X. Wang and S.-R. Yang are with the Department of Computer Science and the Institute of Communications Engineering, National Tsing Hua University, Hsinchu 30013, Taiwan (e-mail: sryang@cs.nthu.edu.tw). Thanks: H. Hung is with the Institute of Statistics, National Chiao Tung University, Hsinchu, Taiwan (e-mail: hhung@stat.nctu.edu.tw). Abstract 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. On a reproduced Tainan SUMO scenario (seed 42), HLSR reduces mean travel time to 380.6380.6 s at 80008000 vehicles, outperforming same-scope live-only controls (438.1438.1 s selective live; 391.6391.6 s scoped live Dijkstra) and remaining competitive with network-wide live travel-time Dijkstra (408.1408.1 s), while intervening on far fewer vehicles than a full-network policy; under the same protocol at 1600016000 and 2000020000 vehicles, HLSR remains best at 895.7895.7 s and 971.7971.7 s. Index Terms: Traffic congestion detection, selective vehicle rerouting, hybrid live–forecast routing, travel-time prediction, SUMO I Introduction The population gradually moves from rural areas to cities. A United Nations report [10] estimates that two-thirds of the world’s population will live in urban areas by 2050. Population growth increases traffic pressure, and road-capacity expansion alone is difficult to sustain because of cost and spatial constraints. Current route navigation systems such as TomTom [14] and Google Maps [7] plan routes from infrastructure-based traffic information, but they cannot reliably replan vehicles that are already en route. Navigation without dynamic network-wide monitoring can even worsen congestion by funneling demand onto links with insufficient capacity. Intelligent transportation systems therefore combine connected sensing, edge/cloud computing, and data-driven control to mitigate congestion in real time. Vehicle rerouting is a validated approach in this setting: when a segment becomes congested, the platform assigns alternative routes so that affected vehicles avoid the bottleneck and reduce travel time. Typical rerouting proceeds in three steps—congestion detection, rerouted-vehicle selection, and alternative-route allocation—yet existing methods leave recurring limitations in each step. Single-indicator or locally scoped detectors often miss heterogeneous congestion patterns and network-wide coupling. Fixed spatial windows and greedy congestion-weighted selection tend to over-reroute distant vehicles or under-react to upstream traffic approaching a bottleneck. Route-allocation policies based only on current live traffic omit short-horizon forecast information needed for segments that will be traversed in later decision periods. Section I reviews representative prior work along these three dimensions. To address these gaps, we introduce HLSR (Hybrid Live–Forecast Selective Rerouting), a selective congestion-alleviation framework. HLSR retains the three-phase structure above and strengthens it with hybrid live–forecast costing so that only congestion-related vehicles are replanned, while near-term decisions still react to observed speeds. The contributions of our work can be summarized as: • Proactive selective rerouting under bounded intervention: HLSR integrates dual-threshold congestion detection, a calibrated upstream hop depth, and approaching-vehicle expansion so that rerouting remains limited to congestion-related vehicles. In the primary setting at 80008000 vehicles, this selective stack reduces mean travel time from 664.2664.2 s (BC) to 438.1438.1 s (HLSR-LIVE). • Hybrid live–forecast route costing: For each candidate route, HLSR blends live and predicted segment speeds with a horizon-dependent weight and applies travel-time-weighted k-shortest-path generation plus multi-cost allocation. Under matched selective candidate scope, this hybrid costing further improves travel time from 438.1438.1 s (HLSR-LIVE) to 380.6380.6 s (HLSR). • Driver-aware travel-time prediction module: A network-level spatial–temporal forecaster (LSTAN_GERPE, optionally ranking-fine-tuned) supplies the forecast branch of the hybrid cost, with driver-behavior and footprint adjustments for personalization, rather than serving as a stand-alone end-to-end rerouter. • Fair-scope evaluation: On the primary Tainan evaluation setting (SUMO seed 4242) at 80008000, 1600016000, and 2000020000 vehicles, we compare HLSR against classical selective baselines (NRR, ReFOCUS+), the reimplemented Du-GAQ method, a prior HLSR-Rank checkpoint, same-scope live-only controls, and network-wide live travel-time Dijkstra, reporting travel time, time loss, waiting time, route length, and reroute count. The remainder of this paper is organized as follows. Section I reviews prior rerouting methods by phase. Section I formalizes the system model and sensing quantities. Section IV details the travel-time prediction module that supplies multi-horizon predicted segment speeds VpredV^pred. Section V assembles the HLSR selective rerouting loop, including hybrid live–forecast costing and the proactive extensions. Section VI reports the experimental settings and results. The paper concludes with limitations and future work. I Related Work Vehicle rerouting alleviates congestion by detecting bottlenecks, selecting vehicles to replan, and assigning alternative routes. The literature is organized below along these three phases, which also structure HLSR. I-A Congestion Detection Proactive rerouting systems must declare congestion before downstream queues fully form. [11] couples detection with rerouting but relies on a single traffic-density indicator, which is insufficient when occupancy and speed diverge. [9] performs distributed detection through V2V cooperation, yet its single-vehicle velocity assumption and local neighborhood scope limit network-wide consistency. [12] combines segment-level and zone-level real-time scores, but aggregated indicators can still misclassify localized or transient congestion. Dual-threshold designs that jointly monitor occupancy and velocity, together with severity-aware triggers, are therefore preferable for selective intervention. I-B Rerouted-Vehicle Selection Once congestion is detected, the controller must decide which vehicles to replan without flooding the network with unnecessary route changes. [5] weights all segments by congestion degree and greedily steers vehicles toward locally minimal-cost edges, which can inflate path length and shift congestion elsewhere. [2] randomly selects a fixed number of vehicles near a forecast congestion footprint, yet vehicles far from the bottleneck may be included while nearer upstream traffic is missed. A common alternative frames a spatial window around the congested segment and reroutes all vehicles inside it. [4] jointly optimizes rerouting and signal control but fixes the window size a priori; [15] broadcasts alarms through intelligent traffic lights with a fixed-level range; and [13] applies breadth-first search with a maximum depth, again using a static range. Fixed windows tend to over-reroute in mild congestion and under-reroute when severity grows, motivating a calibrated upstream hop depth together with approaching-vehicle expansion. I-C Alternative Route Allocation The final phase assigns one or more candidate routes to each selected vehicle. Single-path policies risk shifting congestion from one area to another, so multi-path and multi-cost schemes are widely adopted. [15] scores routes from current real-time network states, whereas [12] combines roadside-unit and traffic-management-center data through a Shannon-entropy router. Learning-based alternatives similarly emphasize live or region-level indices. For example, [6] couples fog-cloud GAQ with entropy-balanced k-shortest paths. Both families, however, rely primarily on present traffic conditions and do not explicitly fuse short-horizon forecasts with live sensing for segments that will be entered in future decision windows. Because road conditions evolve within each aggregation period, costing that blends near-term live speed with horizon-indexed predictions is needed for routes whose traversal extends beyond the current observation instant. Collectively, prior selective rerouting methods improve individual phases but rarely integrate (i) dual-threshold detection, (i) calibrated upstream and approaching-vehicle selection under bounded intervention, and (i) hybrid live–forecast multi-cost allocation supported by a network-level forecaster. HLSR targets this integration gap while keeping forecasting as a supporting module rather than a stand-alone end-to-end rerouter. I System Model This section first introduces the road-network representation and the zone partition under which HLSR operates. Second, the platform architecture and the sensing quantities maintained at each decision instant are presented. Third, we define the live and predicted speed values together with the travel-time components that later modules compose into route costs. I-A Road Network and Zone Partition We consider a directed urban road network whose atomic elements are road segments (edges); let S denote the full set of segments. The network is partitioned into NzN_z city zones z1,z2,…,zNz\z_1,z_2,…,z_N_z\. Without loss of generality, zone zpz_p contains NrsN_rs road segments denoted sp(1),…,sp(Nrs)\s_p^(1),…,s_p^(N_rs)\. Each segment s is characterized by length Lrs(s)L_rs(s), lane count Nl(s)N_l(s), and speed limit Vlim(s)V^lim(s). Vehicles v report locations and destinations to the platform. τ denotes wall-clock time at a decision instant. The candidate-route budget NcrN_cr is the maximum number of alternative paths retained for each replanned vehicle (default Ncr=7N_cr=7 in our deployment). In our scenario, vehicle arrivals and destinations are treated as an exogenous demand process independent of the selective controller, whereas congestion detection, vehicle selection, and hybrid route allocation constitute the joint controllable decision space optimized by HLSR. I-B Platform Architecture and Sensing In Fig. 1, we demonstrate the cloud-hosted vehicle rerouting architecture that integrates roadside sensing with centralized selective control, wherein the transportation authority maintains a consistent view of segment occupancy and mean speed under periodic detector exports and vehicle location reports. Fig. 1: Activity diagram of the traffic rerouting system. In this architecture, roadside units periodically collect vehicle locations and destinations, while closed-circuit televisions and velocity / loop detectors export per-segment occupancy and mean-speed traces. Location and destination reports allow the platform to maintain the vehicle count Nv(s,τ)N_v(s,τ) on each segment and to push updated routes to selected vehicles. Detector exports supervise the travel-time prediction module of Sec. IV and, at runtime, provide the live edge speeds consumed by hybrid costing in Sec. V. I-C Occupancy and Velocity Observables From the maintained counts and speeds, the platform computes two normalized indicators that later enter congestion detection. Let Nv(s,τ)N_v(s,τ) denote the number of vehicles on segment s at time τ. The road occupancy ratio is defined as RO(s,τ)=Nv(s,τ)Nvmax(s),R_O(s,τ)= N_v(s,τ)N_v^max(s), (1) where the segment capacity is Nvmax(s)=Lrs(s)L¯v+Lsd×Nl(s),N_v^max(s)= L_rs(s) L_v+L_sd× N_l(s), (2) with average vehicle length L¯v L_v and safe spacing LsdL_sd. The road velocity ratio is likewise defined as RV(s,τ)=V¯(s,τ)Vlim(s),R_V(s,τ)= V(s,τ)V^lim(s), (3) where V¯(s,τ) V(s,τ) is the mean speed on s at τ. We model a discrete decision structure in which each aggregation window comprises an interval of length T (default T=300T=300 s), indexed at successive window boundaries. Occupancy and speed statistics are accumulated over each window, and the selective control loop of Sec. V is invoked at those boundaries. Consequently, ROR_O and RVR_V furnish the measurable congestion state against which threshold-based detection operates, whereas route allocation itself is driven by the speed values introduced next. I-D Live and Predicted Speed Values At decision time τ, live and predicted speed values are available for costing candidate routes. The live speed value Vlive(s,τ)V^live(s,τ) is the current mean speed on segment s obtained from live sensing (TraCI / detectors). The predicted speed values Vpred(s,τ,h)V^pred(s,τ,h) are a multi-horizon forecast on s at horizon index h=1,…,Touth=1,…,T_out, where ToutT_out is the forecast horizon length, produced by the travel-time prediction module of Sec. IV. HLSR never treats the predicted speed values as a stand-alone rerouter: Phase 3 of Sec. V blends VliveV^live and VpredV^pred with a horizon-dependent weight, wherein near-term edges place greater trust in live sensing while farther edges rely more on forecast foresight. Thus, live observations remain the authoritative near-horizon reference, whereas predicted speeds extend costing beyond the immediate sensing horizon without replacing selective control. I-E Travel-Time Components When a vehicle vrv_r is scored on a candidate route rk(vr,τ)=sk(1)→⋯→sk(∥rk∥)r_k(v_r,τ)=\s_k^(1)\!→\!·s\!→\!s_k^( r_k )\, where ∥rk∥ r_k denotes the number of segments on rkr_k, the segment travel time tv(sk(j)(vr,τ))t_v(s_k^(j)(v_r,τ)) decomposes into traffic-light queueing delay tqt_q and road-segment passing time tpt_p. The queueing model follows our earlier traffic-light formulation [18]. The passing time is obtained from a (hybrid) segment speed and, when enabled, a driver-tailored correction. Sec. IV specifies how VpredV^pred and the driver factor are computed and illustrates the component breakdown. Sec. V specifies how those speeds are blended and embedded in multi-cost route allocation. IV Travel Time Prediction This section specifies the travel-time prediction module that supplies multi-horizon predicted speed values Vpred(s,τ,h)V^pred(s,τ,h) for hybrid live–forecast route costing. It is not a stand-alone rerouting policy: the forecast is later blended with live speeds under a horizon-dependent weight, while selective vehicle selection remains separate. Building on the sensing metrics and travel-time components of Sec. I, we adopt our previously published spatio-temporal forecaster LSTAN_GERPE [16] to emit network-wide speed values. For the recommended HLSR configuration, the model is initialized from pretrained Huber weights and optionally fine-tuned by freezing the encoder and adapting only the output head with an additional path-ranking loss, so that candidate-route order is better preserved under route allocation. Driver-behavior personalization further maps the network-level forecast into vehicle-specific segment speeds for the selected candidates. IV-A Forecasting Design On forecasting vrv_r’s travel time tv(sk(j)(vr,τ))t_v(s_k^(j)(v_r,τ)) over segment sk(j)(vr,τ)s_k^(j)(v_r,τ) at a desired instant τj _j, a common practice is to predict edge speeds from recent local observations and convert those speeds into segment travel times. For selective hybrid rerouting, two issues matter more than edge-level regression accuracy alone. First, because HLSR scores full candidate routes rather than isolated sensors, forecast errors that preserve edge-level RMSE may still invert path rankings; the forecaster must therefore be trained and evaluated with route-level discrimination in mind. Second, since HLSR predicts tvt_v for a specific vehicle vrv_r, the driver’s tendency to travel faster or slower than average also influences personalization accuracy. Taking these observations into account, we use a two-stage prediction stack: IV-A1 Network-level speed-value prediction A spatial–temporal forecaster (LSTAN_GERPE) consumes a short history of network-wide mean speed and occupancy and emits multi-horizon predicted speed values Vpred(s,τ,h)V^pred(s,τ,h) for every segment s and horizon index h. Daily recurring patterns are captured by GERPE pattern keys rather than by fitting a separate model per edge. IV-A2 Driver-tailored segment average velocity Given the network-level prediction for segment sk(j)(vr,τ)s_k^(j)(v_r,τ), a driver-behavior model maps the predicted speed into a vehicle-specific average velocity VA(⋅)V_A(·) using the driver’s behavior parameter Bd(vr,s)Bd(v_r,s) and a calibrated factor Δ . Together with a traffic-light delay model, this yields tv(sk(j)(vr,τ))t_v(s_k^(j)(v_r,τ)). The resulting personalized speed is consumed as the forecast branch of hybrid costing and does not replace live sensing for near-horizon segments. IV-B The Prediction Framework Given the current time τ as the entering time into the candidate shortest route rk(vr,τ)r_k(v_r,τ), our framework operates iteratively as follows: provided with the estimated entering time τj _j into the road segment sk(j)(vr,τ)s_k^(j)(v_r,τ) obtained in the (j−1j-1)-th iteration, our framework predicts the travel time tv(sk(j)(vr,τ))t_v(s_k^(j)(v_r,τ)) over sk(j)(vr,τ)s_k^(j)(v_r,τ) and the entering time τj+1 _j+1 into the next road segment sk(j+1)(vr,τ)s_k^(j+1)(v_r,τ) in the j-th iteration. Fig. 2 illustrates the component elements of tv(sk(j)(vr,τ))t_v(s_k^(j)(v_r,τ)), which are further explained below. Fig. 2: Travel time component elements IV-B1 Traffic light queueing time tq(sk(j)(vr,τ))t_q(s_k^(j)(v_r,τ)) This represents the delay that vehicle vrv_r should face at the entrance intersection of sk(j)(vr,τ)s_k^(j)(v_r,τ) due to a red traffic light upon the estimated entering time τj _j, which consists of 1) the remaining red-light time and 2) the transient residence time at the entrance intersection after the traffic light changes to green. Our framework applies the traffic light model we developed in [18] to estimate the two time segments, based on the pre-defined traffic-light signal timing plans (from the government transportation department) and a probabilistic model, respectively. The readers are referred to [18] for the details. IV-B2 Road segment passing time tp(sk(j)(vr,τ))t_p(s_k^(j)(v_r,τ)) Let τ(j) _(j) be τj+tq(sk(j)(vr,τ)) _j+t_q(s_k^(j)(v_r,τ)), representing the instant when vrv_r leaves the traffic light and starts to cross sk(j)(vr,τ)s_k^(j)(v_r,τ). Let the horizon index aligned with τ(j) _(j) be hj=⌊τ(j)−τT⌋+,h_j= _(j)-τT _+, (4) where T is the aggregation period of Sec. I and [⋅]+[·]_+ clips negative values to zero. Our framework forecasts tp(sk(j)(vr,τ))t_p(s_k^(j)(v_r,τ)) as follows: 1) the network-level forecaster supplies Vpred(sk(j),τ,hj)V^pred(s_k^(j),τ,h_j); 2) the driver-tailored model maps this speed to vrv_r’s average velocity VA(sk(j)(vr,τ),τ(j),Bd(vr,sk(j)))V_A(s_k^(j)(v_r,τ), _(j),Bd(v_r,s_k^(j))) using the behavior parameter BdBd introduced above; 3) finally, tp(sk(j)(vr,τ))=Lrs(sk(j)(vr,τ))VA(sk(j)(vr,τ),τ(j),Bd(vr,sk(j))).t_p(s_k^(j)(v_r,τ))= L_rs(s_k^(j)(v_r,τ))V_A(s_k^(j)(v_r,τ), _(j),Bd(v_r,s_k^(j))). The network-level forecaster and the driver-tailored model are elaborated in the following subsections. IV-C Network‑Level Spatio‑Temporal Forecaster This subsection details the forecasting module deployed within the HLSR framework. A per‑edge LSTM stack is retained solely as an ablation baseline for comparative evaluation under the proposed HLSR pipeline and is not incorporated into our final recommended approach. IV-C1 Network‑Wide Speed‑Value Formulation Let S denote the set of road segments as in Sec. I, corresponding to nodes in the directed road graph, and N=||N=|S| be its cardinality. At decision instant τ, measurements collected from loop detectors construct a historical input tensor τ=x(s,τ−i)s∈,i=0,…,Tin−1∈ℝTin×N×F,X_τ= \x(s,τ-i) \_s ,\,i=0,…,T_in-1 ^T_in× N× F, (5) where the input time window Tin=12T_in=12 (one-minute time steps), and feature dimension F=2F=2 stacks mean speed and occupancy. The forecasting model fθf_θ projects τX_τ toward multi‑horizon segment‑wise speed predictions: Vpred(s,τ,h)=fθ(τ;Llap)s,h,h=1,…,Tout,V^pred(s,τ,h)=f_θ (X_τ;\,L_lap )_s,h, h=1,…,T_out, (6) in which Tout=6T_out=6 defines the prediction horizon length, and LlapL_lap denotes Laplacian positional encoding derived from the road graph. During route assignment, Vpred(s,τ,h)V^pred(s,τ,h) is fused with real‑time observed speeds in a horizon‑adaptive manner. Near‑future horizons prioritize live sensor measurements, whereas segments further ahead rely more heavily on model‑predicted speed values. Different from per‑edge sequential predictors that maintain an independent model instance for each detector, one single model forward pass produces globally consistent network‑wide speed estimates shared by all candidate routing alternatives within the same decision cycle. IV-C2 LSTAN‑GERPE Architecture The network-level forecaster adopts our previously published LSTAN_GERPE model [16], which we reuse as the speed-prediction backbone for HLSR. Briefly, it implements a graph-aware encoder–decoder architecture. Laplacian graph embedding, rotary positional encoding, and stacked spatio-temporal attention blocks jointly model geographic adjacency, semantic correlation among road segments, and temporal traffic evolution. The multi-horizon decoder outputs Vpred(s,τ,h)V^pred(s,τ,h) for h=1,…,Touth=1,…,T_out. Pretraining follows the same Huber regression objective as in our prior work [16]. Consequently, the edge-level Huber loss ℒHuberL_Huber adopted herein inherits from that backbone and does not constitute a novel contribution of this paper. Table I summarizes hyperparameter settings when integrating this backbone into HLSR. Comprehensive architectural descriptions can be found in [16]. TABLE I: Default hyperparameters of LSTAN_GERPE for speed–occupancy inputs, adopted from our prior work [16]. Parameter Value Input / output window (TinT_in, ToutT_out) 1212, 66 Features F speed, occupancy Embed / skip dimension 6464 / 256256 Encoder depth D 66 Geo / sem / temporal attention heads 44 / 22 / 22 Geographic hop mask Δfar _far 77 Training loss Huber (δ=2δ=2) [16] IV-C3 Reroute‑Aligned Fine‑Tuning Pure edge‑level regression accuracy cannot guarantee correct ranking of candidate routes under multi‑objective route allocation. Even forecasts yielding acceptable Huber residuals may invert the relative travel‑time ordering between complete paths, which consequently leads to sub‑optimal route selections. To mitigate this issue, we optionally fine-tune a ranking-aware variant denoted LSTAN_GERPE_rank. During fine-tuning, the encoder of our pretrained LSTAN_GERPE [16] is kept frozen; only the prediction output head is adapted via an OD-based k-shortest-path ranking loss. The composite training objective reads ℒ=ℒHuber+λrankℒod_ksp,L=L_Huber+ _rank\,L_od\_ksp, (7) where ℒHuberL_Huber denotes the original backbone Huber loss for speed-value regression inherited from our prior work [16], and λrank _rank is a small weighting coefficient. It softly regularizes route-order consistency without overriding the pretrained speed representations. The ranking loss term is constructed to mimic the candidate‑path comparison procedure within route allocation. For each origin‑destination (OD) pair o encountered in selective rerouting demands from the SUMO simulator, we precompute a set o=Po,1,…,Po,KP_o=\P_o,1,…,P_o,K\ of K loop‑free k‑shortest paths [19] over the directed road graph, with K=NcrK=N_cr matching the candidate‑route budget defined in Sec. I. Given segment‑wise speed values V, the travel time of a path P is computed by aggregating edge travel times: T(P,V)=∑e∈PLrs(e)max(V(e),ε),T(P;V)= _e∈ P L_rs(e) (V(e), ), (8) where ε>0 >0 is a small positive constant for numerical stability. By substituting the predicted speed values VpredV^pred and ground-truth detector-measured speeds V∗V^* into (8), we obtain predicted path travel times T^(P) T(P) and ground-truth path travel times T∗(P)T^*(P), respectively. Within each OD candidate set oP_o, we sample path pairs (Pi,Pj)(P_i,P_j). Only pairs whose ground‑truth time difference exceeds a threshold tmint_ are retained, such that near‑tie samples do not dominate gradient updates. Let ΔT∗=T∗(Pi)−T∗(Pj) T^*=T^*(P_i)-T^*(P_j) denote the ground‑truth travel‑time difference and ΔT^=T^(Pi)−T^(Pj) T= T(P_i)- T(P_j) denote its predicted counterpart. The pairwise logistic ranking penalty is formulated as ℓ(i,j)=log(1+exp(−sign(ΔT∗)ΔT^)), (i,j)= (1+ (-sign( T^*)\, T ) ), (9) which approaches zero when predicted path ordering aligns with ground truth and increases as ranking inversion occurs. Averaging (9) across sampled mini‑batch OD pairs, valid filtered path pairs, and all prediction horizons yields the final ranking loss: ℒod_ksp=1|ℋ|||∑h∈ℋ∑o∈1|o|∑(i,j)∈oℓh(i,j),L_od\_ksp= 1|H|\,|O| _h _o 1|Q_o| _(i,j) _o _h(i,j), (10) where O is the collection of OD pairs within one mini‑batch, oQ_o stands for the filtered valid path subset of oP_o, and ℋH represents the set of prediction horizons for VpredV^pred. Since pairwise comparisons are constrained to k‑shortest candidate paths sharing identical origin‑destination pairs, ℒod_kspL_od\_ksp directly regularizes the path‑discrimination task faced by route allocation, instead of performing arbitrary pairwise comparisons over isolated road segments or random graph walks. Fine-tuning is performed in a closed loop with the selective rerouting simulator: updated forecasts are redeployed in HLSR, and the resulting traffic measurements supervise the next ranking update of the output head under a reduced learning rate. This refinement improves path-ranking discrimination while keeping the overall HLSR rerouting pipeline unchanged. Quantitative closed-loop comparisons among HLSR-LSTM, HLSR-Huber, and Rank-backed HLSR are reported in the experimental evaluation. IV-D Driver-Tailored Segment Average Velocity IV-D1 Assumption and definition We take the assumption that we can get road segment s monitoring velocity and each vehicle vrv_r historical traffic information like velocity, entry time and exit time. Single vehicle average velocity V¯(s,τ,vr) V(s,τ,v_r) is calculated as equation 11, where trvr(τx)t_r^v_r( _x) and trvr(τy)t_r^v_r( _y) are the measured exit time and entry time of vehicle vrv_r on road segment r from detailed traffic data, respectively. Lrs(s)L_rs(s) is the length of road segment s. V¯(s,τ,vr)=Lrs(s)trvr(τx)−trvr(τy) V(s,τ,v_r)= L_rs(s)t_r^v_r( _x)-t_r^v_r( _y) (11) We consider driver’s pattern which depends on many factors, such as automobile performance, driver’s physiological condition and personal emotion, and express the complicated driver pattern as a simple driver behavior parameter Bd(v,s)Bd(v,s) (Fig. 3). Fig. 3: Definition of the driver behavior parameter Behavior parameter Bd(vr,s)Bd(v_r,s) is calculated as equation 12. Bd(vr,s)=Vhis¯(s,vr)−Vhis¯(s,vN)Vhis¯(s,vM)−Vhis¯(s,vN)Bd(v_r,s)= V_his(s,v_r)- V_his(s,v_N) V_his(s,v_M)- V_his(s,v_N) (12) which is a Min-Max-Scaler normalization, where Vhis¯(s,vr) V_his(s,v_r) is historical average velocity of vrv_r, Vhis¯(s,vM) V_his(s,v_M) is historical average velocity of vehicle vMv_M with the maximum historical average velocity of all vehicles, Vhis¯(s,vN) V_his(s,v_N) is historical average velocity of vehicle vNv_N with the minimum historical average velocity of all vehicles. The relationship between single vehicle average velocity V¯(s,τ,vr) V(s,τ,v_r) and the network-level (predicted or live) segment speed V(s,τ)V(s,τ) is expressed in equation 13. V¯(s,τ,vr)=V(s,τ)×Δ V(s,τ,v_r)=V(s,τ)× (13) We define Δ as driver-tailored factor which is correlated to per driver behavior parameter Bd(vr,s)Bd(v_r,s). IV-D2 Determination of Δ Data acquisition and normalization. Based on traffic data and equation (11), the vehicles’ average velocity is V¯set=V¯(s,τ,vr0),V¯(s,τ,vr1),….,V¯(s,τ,vrns−1) V_set=\ V(s,τ,v_r^0), V(s,τ,v_r^1),...., V(s,τ,v_r^n_s-1)\, where nsn_s corresponds to the data size which stands for number of vehicles. Next, based on road detector information, we get the road instantaneous velocity named as Vset=V(s,τ,vr0),V(s,τ,vr1),….,V(s,τ,vrns−1)V_set=\V(s,τ,v_r^0),V(s,τ,v_r^1),....,V(s,τ,v_r^n_s-1)\, where V(s,τ,vrns−1)V(s,τ,v_r^n_s-1) is the instantaneous velocity at time τ for road segment s where vehicle vrns−1v_r^n_s-1 is exactly on. we use zns−1sz_n_s-1^s stands for V¯(s,τ,vrns−1)V(s,τ,vrns−1) V(s,τ,v_r^n_s-1)V(s,τ,v_r^n_s-1), Next, we divide parallel elements in set V¯set V_set and VsetV_set, gaining Zsetratio=z0s,z1s,….,zns−1sZ_set^ratio=\z_0^s,z_1^s,....,z_n_s-1^s\. Then, we normalize zjs(j∈[0,ns−1])z_j^s(j∈[0,n_s-1]) to zj∗s∈(0,1)z_j^*s∈(0,1) by linear transformation shown in equation 14, improving prediction efficiency. The prediction performance works better for cases in which nsn_s is large enough. zj∗s= z_j^*s= zjs−zminszmaxs−zmins×ns−1ns+12×ns, z_j^s-z_min^sz_max^s-z_min^s× n_s-1n_s+ 12× n_s, (14) zmaxs= z_max^s= maxj=0,…ns−1zjs, _j=0,...n_s-1z_j^s, zmins= z_min^s= minj=0,…ns−1zjs _j=0,...n_s-1z_j^s Next, we describe how we estimate Δ . We select fifty vehicles on each road segment and derive the related zjs(j∈[0,49])z_j^s(j∈[0,49]). The observation layout and empirical CDFs used in calibration are reported with the prediction-module checks in the experimental evaluation. Let z denote one of the zjsz_j^s values and nzn_z the number of occurrences of that value, so that p(zs)=nz/50p(z^s)=n_z/50. Because zsz^s is discrete, its cumulative distribution function is F(zs)=∑Z≤zsp(zs).F(z^s)=Σ _Z≤ z^sp(z^s). (15) Empirical CDFs of zsz^s on detector segments are close to a power function. We therefore approximate F(zs)F(z^s) by a parametric CDF of Δ and estimate the power via maximum likelihood [1]: ηs=−ns∑j=0j=ns−1lnzj∗. _s=- n_s _j=0^j=n_s-1lnz_j^*. (16) Calculate (Bd)ηs(Bd) _s and compress it in the x-direction by multiplying (zmax−zmin)(z_ -z_ ) to match the shape of F(zs)F(z^s), then shift right by adding zminz_ . As mentioned above, let V^(s,τ,vr) V(s,τ,v_r) (equivalently VAV_A) be the predicted average velocity of vehicle vrv_r on segment s at time τ, BdBd the driver behavior parameter, and V(s,τ)V(s,τ) the network-level segment speed (predicted speed values or live observation). The relationship between average velocity and segment speed is then V^(s,τ,vr)= V(s,τ,v_r)= V(s,τ)×[(zmaxs−zmins)×(Bd)ηs+zmins] V(s,τ)×[(z_max^s-z_min^s)×(Bd) _s+z_min^s] (17) = = V(s,τ)×Δ V(s,τ)× with Δ=[(zmaxs−zmins)×(Bd)ηs+zmins]. =[(z_max^s-z_min^s)×(Bd) _s+z_min^s]. (18) Empirical agreement between F(z)F(z) and F(Δ)F( ), together with the calibrated (zmin,zmax,η)(z_ ,z_ ,η) values, is verified in the experimental evaluation. IV-D3 Time Cost Calculation Given the predicted segment speeds from Sec. IV-C and the driver factor Δ from (18), Algorithm 1 accumulates route travel time for candidate rk(vr,τ)r_k(v_r,τ). For each segment sk(j)s_k^(j) on the route, the forecaster supplies Vpred(sk(j),τ,hj)V^pred(s_k^(j),τ,h_j), the driver-tailored model yields V^(sk(j)(vr,τ),τ) V(s_k^(j)(v_r,τ),τ) via (17), and the segment time Lrs/V^L_rs/ V is added to the route cost. Input : Forecaster fθf_θ and history tensor τX_τ; Per-segment parameters η(sk(j))η(s_k^(j)), zmax(sk(j))z_ (s_k^(j)), zmin(sk(j))z_ (s_k^(j)), Bd(vr,sk(j))Bd(v_r,s_k^(j)), Lrs(sk(j))L_rs(s_k^(j)) for j∈[1,∥rk(vr,τ)∥]j∈[1, r_k(v_r,τ) ]; Output : time cost CrV(rk(vr,τ))C_r^V(r_k(v_r,τ)); Procedure : Compute the network-wide predicted speed values Vpred(⋅,τ,⋅)←fθ(τ,Llap)V^pred(·,τ,·)← f_θ(X_τ;L_lap); CrV(rk(vr,τ))=0C_r^V(r_k(v_r,τ))=0; for j=1j=1; j<=∥rk(vr,τ)∥j<= r_k(v_r,τ) ; j++j++ do V(sk(j),τ)←Vpred(sk(j),τ,hj)V(s_k^(j),τ)← V^pred(s_k^(j),τ,h_j); compute V^(sk(j)(vr,τ),τ) V(s_k^(j)(v_r,τ),τ) using (17); CrV(rk(vr,τ))=CrV(rk(vr,τ))+Lrs(sk(j)(vr,τ))V^(sk(j)(vr,τ),τ)C_r^V(r_k(v_r,τ))=C_r^V(r_k(v_r,τ))+ L_rs(s_k^(j)(v_r,τ)) V(s_k^(j)(v_r,τ),τ); return CrV(rk(vr,τ))C_r^V(r_k(v_r,τ)); Algorithm 1 TC(fθ,τ,Bd,η,zmax,zmin,Lrs)TC(f_θ,X_τ,\Bd,η,z_ ,z_ ,L_rs\) V The Proposed HLSR Framework Built upon the system model and travel-time forecaster from previous sections, this section details HLSR’s selective real-time rerouting loop. Instead of recalculating paths for all vehicles per cycle, HLSR only replans vehicles impacted by congestion. We present its three-phase pipeline in order—congestion detection, vehicle selection, then route allocation—and finally assemble them into the main runtime loop. Core extensions include hybrid live–forecast costing, travel-time weighted k-shortest paths, and approaching-vehicle expansion. Fig. 4 visualizes data flow among live sensing, the prediction module, and the three functional phases. Live SensingVlive,RO,RVV^live,\,R_O,\,R_VTravel-Time ForecasterLSTAN-GERPE + Driver ModelPredicted Speed VpredV^predPhase 1Congestion Detection (TCD)Phase 2Vehicle Selection (RVS)Phase 3Hybrid Route Allocation (ARA) Fig. 4: HLSR runtime pipeline. Roadside sensing data feeds both the three-phase rerouting workflow and forecasting module. Phase 3 fuses live and predicted speeds to compute travel costs for candidate paths. V-A Phase 1: Traffic Congestion Detection The core congestion detection logic is encapsulated in Algorithm 2. This module is structurally split into four standardized functional blocks: input specification, output definition, variable initialization, and execution procedure. V-A1 Input Parameters The detection function accepts five mandatory arguments: 1) Target road segment s for congestion assessment; 2) Current decision timestamp τ; 3) Threshold of occupancy ratio δO _O; 4) Threshold of velocity ratio δV _V; 5) Weight factor for occupancy-based congestion indicator Ψro _ro. V-A2 Output Results Two outputs are returned after execution: a binary flag isCongestedisCongested indicating whether segment s is congested at time τ, and a continuous congestion severity metric RS(s,τ)R_S(s,τ). V-A3 Initialization Stage Two internal variables are initialized before computation: isCongestedisCongested is set to FalseFalse, and the severity score RS(s,τ)R_S(s,τ) is initialized to 00. V-A4 Execution Procedure First, the module calculates normalized occupancy RO(s,τ)R_O(s,τ) and normalized velocity ratio RV(s,τ)R_V(s,τ) using the formulas derived in Sec. I. Congestion is triggered only when both traffic metrics exceed their respective thresholds, i.e., RO(s,τ)>δOR_O(s,τ)> _O and 1−RV(s,τ)>δV1-R_V(s,τ)> _V. Once the dual-threshold condition is satisfied, isCongestedisCongested is assigned to TrueTrue, and the composite congestion severity index is computed via: RS(s,τ) R_S(s,τ) =RO(s,τ)⋅Ψro =R_O(s,τ)· _ro +(1−RV(s,τ))⋅(1−Ψro). + (1-R_V(s,τ) )· (1- _ro ). (19) Finally, the flag isCongestedisCongested and severity value RS(s,τ)R_S(s,τ) are returned as function outputs. Collecting all congested segments at decision time τ yields the congested set (τ)=(s,RS(s,τ))|s∈,isCongested(s,τ).C(τ)= \(s,R_S(s,τ)) |s ,\;isCongested(s,τ) \. (20) Input : Target road segment s; Current timestamp τ; Occupancy threshold δO _O; Velocity ratio threshold δV _V; Occupancy weight Ψro _ro; Output : Congestion flag isCongestedisCongested; Congestion severity RS(s,τ)R_S(s,τ); Initialization : isCongested←FalseisCongested ; RS(s,τ)←0R_S(s,τ)← 0; Procedure : Compute occupancy ratio RO(s,τ)R_O(s,τ) via (1) and (2); Compute velocity ratio RV(s,τ)R_V(s,τ) via (3); if RO(s,τ)>δO∧(1−RV(s,τ))>δVR_O(s,τ)> _O (1-R_V(s,τ))> _V then isCongested←TrueisCongested ; Calculate RS(s,τ)R_S(s,τ) using (19); return isCongestedisCongested, RS(s,τ)R_S(s,τ); Algorithm 2 TCD: Dual-Threshold Traffic Congestion Detection Function V-B Phase 2: Rerouted Vehicle Selection The vehicle screening logic is encapsulated in function RVS, as summarized in Algorithm 3. We break down its inputs, outputs, and computational workflow as follows. V-B1 Input Parameters Three inputs are required for the selection module: 1) Congested target segment scs_c; 2) Current decision timestamp τ; 3) Upstream hop depth θur _ur. V-B2 Output Results The module outputs a vehicle set SrvT(sc,τ)S_rv^T(s_c,τ), which collects all vehicles assigned to rerouting for mitigating congestion on scs_c. V-B3 Execution Procedure We first define Sur(i)(sc,τ)S_ur^(i)(s_c,τ) as the set of i-hop upstream segments of scs_c at timestamp τ. These edges carry traffic flows that will enter scs_c in subsequent aggregation cycles. For illustrative purposes, Fig. 1 gives an example: the 1-hop upstream set Sur(1)(sc,τ)=s1,s5,s8S_ur^(1)(s_c,τ)=\s_1,s_5,s_8\ and the 2-hop upstream set Sur(2)(sc,τ)=s3,s6,s12,s13S_ur^(2)(s_c,τ)=\s_3,s_6,s_12,s_13\. Let θur _ur denote the upstream hop depth, i.e., the maximum upstream layer considered for vehicle selection. A larger θur _ur expands the intervention range but also raises the risk of over-rerouting; the recommended deployment uses θur=9 _ur=9. The full upstream segment pool is the union of hop layers 1,…,θur1,…, _ur: SurT(sc,τ)=⋃i=1θurSur(i)(sc,τ).S_ur^T(s_c,τ)= _i=1 _urS_ur^(i)(s_c,τ). (21) The base candidate vehicle set consists of all vehicles residing within SurT(sc,τ)S_ur^T(s_c,τ) at timestamp τ: SrvT(sc,τ)=vr|vr is located on any segment s∈SurT(sc,τ) at τ.S_rv^T(s_c,τ)= \v_r\, |\,v_r is located on any segment s∈ S_ur^T(s_c,τ) at τ \. (22) Approaching-Vehicle Expansion Mechanism Upstream selection and approaching expansion play complementary roles. The hop budget θur _ur sets a topology window SurT(sc,τ)S_ur^T(s_c,τ): vehicles currently located on those upstream segments form the base intervention set. Approaching expansion then supplements vehicles that lie outside this window yet will enter scs_c shortly along their planned routes. Concretely, a vehicle is added if (i) scs_c remains on its pre-planned route and (i) the number of remaining route hops from its current edge to scs_c is at most two (a fixed near-horizon budget). The final rerouting set for scs_c is the union of the upstream base set and this approaching supplement; when a vehicle appears in both, the smaller hop index is kept for priority sorting. Input : Congested road segment scs_c; Current decision timestamp τ; Upstream hop depth θur _ur; Output : Aggregated rerouting vehicle set SrvT(sc,τ)S_rv^T(s_c,τ) for segment scs_c; Procedure : Aggregate full upstream segment pool SurT(sc,τ)S_ur^T(s_c,τ) using (21); Generate the base vehicle set from SurT(sc,τ)S_ur^T(s_c,τ) via (22); Expand with approaching vehicles outside that window whose remaining route hops to scs_c are in 1,2\1,2\; Return the union, keeping the smaller hop index per vehicle for later sorting; return SrvT(sc,τ)S_rv^T(s_c,τ); Algorithm 3 RVS: Rerouted Vehicle Selection Function V-C Phase 3: Alternative Route Allocation The route assignment logic is encapsulated in function ARA, whose full workflow is summarized in Algorithm 4. The input definitions, sorting strategy, hybrid live–forecast costing, candidate path generation, and multi-objective scoring are elaborated sequentially below. V-C1 Input Parameters The allocation module accepts three mandatory inputs: 1. Current decision timestamp τ; 2. Aggregated rerouting vehicle set SrvT(τ)=⋃(sc,RS)∈(τ)SrvT(sc,τ)S_rv^T(τ)= _(s_c,R_S) (τ)S_rv^T(s_c,τ), merged from Phase 2 outputs over the congested set (τ)C(τ) in (20); 3. Maximum number of candidate paths NcrN_cr reserved for each individual vehicle. V-C2 Execution Procedure For every vehicle requiring rerouting within SrvT(τ)S_rv^T(τ), the module generates NcrN_cr feasible candidate paths and selects the optimal route via multi-objective cost minimization based on horizon-adaptive fused travel speeds. Horizon-Adaptive Live–Forecast Speed Fusion Let Vlive(s,τ)V^live(s,τ) denote real-time segment speed from roadside detectors, and Vpred(s,τ,h)V^pred(s,τ,h) denote personalized predicted speed output by the LSTAN-GERPE forecaster (integrated with driver-behavior calibration from Sec. IV). The proposed fusion strategy avoids over-reliance on pure prediction or raw sensing by assigning horizon-dependent blending coefficients: near-future segments trust live measurements, while far-ahead segments adopt forecasted traffic states: V~(s,τ,h)=α(h)Vlive(s,τ)+(1−α(h))Vpred(s,τ,h). V(s,τ,h)=α(h)\,V^live(s,τ)+ (1-α(h) )\,V^pred(s,τ,h). (23) The live-data weight α(h)α(h) decays linearly with prediction horizon index h, with intercept α0 _0 and per-horizon decay αΔ _ : α(h)=max(0,α0−h⋅αΔ).α(h)= (0, _0-h· _ ). (24) For sufficiently large horizons satisfying h≥⌈α0/αΔ⌉h≥ _0/ _ , α(h)α(h) drops to zero, and the fused speed fully relies on forecasting outputs. Real-time sensing acts as the authoritative reference for near-term traffic, while spatio-temporal forecasts extend cost calculation beyond the single aggregation window without triggering full-network vehicle replanning. Notably, horizon index h does not equal the segment’s sequential position on a route. Instead, h quantifies how many complete aggregation windows will elapse between the decision time τ and the vehicle’s estimated entry instant tint_in of the target segment: h=⌊tin−τT⌋+,h= t_in-τT _+, (25) where T is the aggregation cycle of Sec. I, and [⋅]+[·]_+ clips negative values to zero. The same physical road segment yields distinct h values for different vehicles due to divergent arrival timestamps, leading to unique fused speed weights per individual trajectory. When evaluating a candidate path rk(vr,τ)=sk(1)→sk(2)→…→sk∥rk∥r_k(v_r,τ)=\s_k^(1)→ s_k^(2)→…→ s_k r_k \, we iteratively compute entry time and horizon for each segment along the path: 1. Initialize entry time of the first segment tin(1)←τt_in^(1)←τ; 2. For subsequent segment sk(j)s_k^(j), update arrival timestamp: tin(j)=tin(j−1)+tv(sk(j−1)),t_in^(j)=t_in^(j-1)+t_v (s_k^(j-1) ), (26) where tv(sk(j−1))t_v(s_k^(j-1)) stands for the fused segment travel time (including optional traffic-light queue delay introduced in the travel-time prediction module). The corresponding horizon hjh_j for segment sk(j)s_k^(j) is obtained by substituting tin(j)t_in^(j) into (25), which matches (4) when tin(j)=τ(j)t_in^(j)= _(j). Early route segments carry small hjh_j with dominant live-speed weight, whereas downstream long-distance segments use forecast-heavy fused speeds, matching the “near real-time, far predictive” design principle. Travel-Time Weighted Candidate Generation The raw vehicle set SrvT(τ)S_rv^T(τ) is first reordered into prioritized sequence SˇrvT(τ) S_rv^T(τ) by (i) ascending upstream hop index and (i) descending residual destination distance, so that vehicles near bottlenecks with long residual trips are updated first. We then process each vr∈SˇrvT(τ)v_r∈ S_rv^T(τ) sequentially and construct the candidate path set Scr(vr,τ)=rk(vr,τ)∣k=1,2,…,Ncr.S_cr(v_r,τ)=\r_k(v_r,τ) k=1,2,…,N_cr\. The urban road network is abstracted as a directed graph where vertices represent road segments and directed edges denote legal segment connections. To prioritize time-efficient corridors during candidate generation, we adopt Yen’s K-shortest path algorithm [19] with dynamic travel-time edge weight w(s,τ)=Lrs(s)V~(s,τ,0),w(s,τ)= L_rs(s) V(s,τ,0), (27) using the fused speed V~ V from (23) at the immediate horizon h=0h=0. Unlike traditional length-weighted K-SP, this time-aware weighting scheme pushes fast, low-congestion corridors into the candidate pool before final multi-cost ranking. Multi-Objective Cost Allocation Given candidate path rk(vr,τ)r_k(v_r,τ) with per-segment horizon hjh_j, the fused travel-time cost is accumulated as: Crtt(rk)=∑j=1∥rk∥Lrs(sk(j))V~(sk(j),τ,hj),C_r^t(r_k)= _j=1 r_k L_rs(s_k^(j)) V(s_k^(j),τ,h_j), (28) with optional additive traffic light waiting delay. HLSR jointly optimizes four normalized cost dimensions: travel time CttC^t, path length CdC^d, route similarity penalty CsC^s, and network occupancy balance term CoC^o. All four metrics are min–max normalized over the candidate set Scr(vr,τ)S_cr(v_r,τ) to eliminate magnitude bias (denoted C^tt,C^d,C^s,C^o C^t, C^d, C^s, C^o), and the optimal route is selected via weighted minimization with nonnegative weights wt,wd,ws,wow_t,w_d,w_s,w_o: r^(vr,τ)=argminrk∈Scr(wtC^tt+wdC^d+wsC^s+woC^o). r(v_r,τ)= _r_k∈ S_cr (w_t\, C^t+w_d\, C^d+w_s\, C^s+w_o\, C^o ). (29) The recommended weight combination (wt,wd,ws,wo)=(0.45,0.20,0.15,0.20)(w_t,w_d,w_s,w_o)=(0.45,0.20,0.15,0.20) prioritizes travel efficiency and short paths while introducing mild load balancing to disperse traffic pressure. Vehicles are rerouted sequentially; after each assignment, the platform updates predicted road occupancy footprints such that subsequent route selections account for newly diverted traffic flows. Finally, the platform issues route update instructions for vehicle vrv_r to switch to the optimal path r^(vr,τ) r(v_r,τ). Input : Current decision timestamp τ; Aggregated rerouting vehicle set SrvT(τ)S_rv^T(τ); Maximum candidate route count NcrN_cr; Procedure : SˇrvT(τ)← S^T_rv(τ)← Sort SrvT(τ)S^T_rv(τ) by ascending upstream hop index, then descending residual destination distance; foreach vr∈SˇrvT(τ)v_r∈ S^T_rv(τ) in sorted order do Generate candidate set Scr(vr,τ)S_cr(v_r,τ) via travel-time weighted Yen K-SP using (27); Compute normalized multi-cost scores and select optimal path r^(vr,τ) r(v_r,τ) via (23)–(29); Send rerouting command to vrv_r for route r^(vr,τ) r(v_r,τ); Algorithm 4 ARA: Adaptive Multi-Cost Alternative Route Allocation Function V-D Main Runtime Loop HLSR runs on a centralized cloud platform illustrated in Fig. 1 and co-simulates with the microscopic traffic simulator SUMO via the TraCI interface. During each fixed-length aggregation window, the platform continuously aggregates real-time segment speed and occupancy measurements collected from roadside detectors. Selective rerouting is triggered at each aggregation-window boundary of duration T (Sec. I). Algorithm 5 assembles Phases 1–3: at τ=nTτ=nT, TCD builds (τ)C(τ) via (20); if nonempty, RVS unions per-bottleneck sets into SrvT(τ)S_rv^T(τ), and ARA assigns hybrid live–forecast routes using VpredV^pred from Sec. IV. The algorithm takes inputs S, thresholds δO,δV _O, _V, severity weight Ψro _ro, upstream depth θur _ur, candidate budget NcrN_cr, and period T. After initialization, the main loop advances simulation time step-by-step. When τ=nTτ=nT, window-level statistics are aggregated and every s∈s is scanned by TCD. If (τ)≠∅C(τ)≠ , Phase 2 merges upstream and approaching vehicles and Phase 3 performs one-shot hybrid route assignment. Input : The full set of road segments S; Occupancy threshold δO _O and velocity ratio threshold δV _V; Congestion severity weighting factor Ψro _ro; Upstream hop depth θur _ur; Maximum number of candidate routes NcrN_cr; Aggregation cycle length T; Procedure : while Unfinished trips remain in SUMO simulation do Advance simulation one time step and aggregate live segment speed / occupancy data; if τ aligns with window boundary τ=nTτ=nT then Aggregate window-wise traffic statistics over all s∈s ; (τ)←∅C(τ)← ; foreach s∈s do isCongested,RS(s,τ)←TCD(s,τ,δO,δV)isCongested,\,R_S(s,τ) (s,τ, _O, _V); if isCongestedisCongested then (τ)←(τ)∪(s,RS(s,τ))C(τ) (τ)∪\(s,\,R_S(s,τ))\; if (τ)≠∅C(τ)≠ then SrvT(τ)←⋃(sc,RS)∈(τ)RVS(sc,τ,θur)S^T_rv(τ)← _(s_c,R_S) (τ)RVS(s_c,τ, _ur); ARA(τ,SrvT(τ),Ncr)ARA(τ,S^T_rv(τ),N_cr) /* Trigger forecast inference */ ; 1 Algorithm 5 Main Runtime Loop of the Proposed HLSR Framework VI Performance Evaluation This section evaluates the proposed HLSR framework. We first ablate individual components and forecasters on the 80008000-vehicle Tainan scenario, then compare HLSR with competing rerouting methods under 80008000, 1600016000, and 2000020000 vehicles. VI-A Simulation Settings VI-A1 Simulation Platform and Road Network HLSR is implemented in Python and co‑simulated with Eclipse SUMO 1.18 [3, 8] via the TraCI interface, where the models presented in Secs. I–V are executed atop a microscopic traffic simulation engine. Deep‑learning forecasting modules are trained using PyTorch 1.13.1. Our simulation testbed covers the West Central District of Tainan. The road network is imported from OpenStreetMap and preprocessed with the Netconvert tool, yielding a topology consisting of 204204 intersections, 561561 road segments, and 77.377.3 km of total roadway length. The network is further divided into 1414 traffic‑analysis zones (TAZs). Among them, five zones serve as traffic origins (Z4,Z10,Z12,Z13,Z14Z_4,Z_10,Z_12,Z_13,Z_14) and four act as destinations (Z2,Z3,Z6,Z9Z_2,Z_3,Z_6,Z_9), which together construct 2020 unique origin–destination (OD) pairs, as visualized in Fig. 5. Vehicle travel demand is injected within a 72007200 s simulation window and uniformly partitioned into four successive 18001800 s intervals. Specifically, 25%25\% of total vehicles are released in each time slot: [0,1800)[0,1800), [1800,3600)[1800,3600), [3600,5400)[3600,5400), and [5400,7200)[5400,7200) s. Three traffic‑demand scales, namely 80008000, 1600016000, and 2000020000 vehicles, are evaluated on this fixed network topology. Each simulation trial runs until all generated vehicle trips are fully completed. Fig. 5: Fourteen TAZs on the Tainan testbed (origins Z4,Z10,Z12,Z13,Z14Z_4,Z_10,Z_12,Z_13,Z_14; destinations Z2,Z3,Z6,Z9Z_2,Z_3,Z_6,Z_9). VI-A2 Evaluation Parameters All experiments use SUMO seed 4242 and aggregation period T=300T=300 s. The candidate-route budget is Ncr=7N_cr=7; thirty reduced-demand pilots showed that a larger budget does not further reduce mean travel time. On this protocol, recommended HLSR uses dual-threshold detection (δO,δV)=(0.55,0.45)( _O, _V)=(0.55,0.45), hybrid blending (α0,αΔ)=(0.75,0.12)( _0, _ )=(0.75,0.12), multi-cost weights (wt,wd,ws,wo)=(0.45,0.20,0.15,0.20)(w_t,w_d,w_s,w_o)=(0.45,0.20,0.15,0.20), and approaching expansion with two remaining route hops. Average vehicle length and safe spacing follow the SUMO defaults L¯v=5 L_v=5 m and Lsd=2.5L_sd=2.5 m. The remaining stack parameter is the upstream hop depth θur _ur: a shallow window localizes intervention, whereas a deep window can over-reroute. Holding the settings above fixed, we sweep θur∈1,…,11 _ur∈\1,…,11\ at 80008000 vehicles (Fig. 6). Mean travel time is high at θur=1 _ur=1 and 22, then nearly flat for θur∈[3,8] _ur∈[3,8] (384.4384.4–390.5390.5 s), while mean reroutes per vehicle increase almost monotonically. The minimum is at θur=9 _ur=9 (380.6380.6 s), with θur=10 _ur=10 essentially tied (380.8380.8 s); θur=11 _ur=11 rises to 388.0388.0 s and the highest reroute rate (0.690.69). Subsequent HLSR rows in TABLES I–I therefore use θur=9 _ur=9. TABLE I also reports a shallower setting θur=4 _ur=4, which lies in the flat mid-range of Fig. 6 and is slightly worse. Fig. 6: Upstream-depth sweep on the recommended HLSR stack (80008000 vehicles, SUMO seed 4242). The highlighted marker is θur=9 _ur=9. VI-A3 Travel‑Time Prediction Setup The travel‑time prediction module generates multi‑horizon predicted speed outputs VpredV^pred, which serve as the forecast inputs for hybrid cost computation in Phase 3. Loop detectors deployed across the Tainan road network (Fig. 7) output per‑minute measurements of link‑level speed and occupancy. These time‑series observations are assembled into the historical input tensor τX_τ and drive the closed‑loop fine‑tuning procedure for the ranking‑enhanced LSTAN_GERPE model. Fig. 7: Loop‑detector placement on the Tainan SUMO network for per‑minute edge‑speed and occupancy export. The network‑wide forecasting backbone is pre‑trained following the protocol described in our prior work [16]. For the recommended HLSR configuration, the encoder weights are frozen, and only the prediction head is fine‑tuned with the OD‑aware k‑shortest‑path ranking loss. The fine‑tuning hyperparameters are set as: λrank=0.015 _rank=0.015, minimum path travel‑time threshold tmin=10t_ =10 s, mini‑batch size containing eight OD pairs (up to 3232 candidate paths per OD pair), and learning rate 5×10−55×10^-5. A prototype per‑edge LSTM model is preserved solely as an ablation baseline, corresponding to the HLSR‑LSTM entry in TABLE I. Driver‑behavior parameters defined in (17) are calibrated using traffic traces collected from SUMO simulation and real‑world detector records in Taipei. Empirical cumulative distribution functions (CDFs) of zjsz_j^s validate the power‑law formulation adopted for the driver‑tailored factor Δ in (18). Fig. 8 provides a representative CDF comparison between empirical F(z)F(z) and model‑fitted F(Δ)F( ) for Nanjing Road; Civic Street and Xinyi Street exhibit consistent fitting performance. Fig. 8: Representative fit of model F(Δ)F( ) to empirical F(z)F(z) (Nanjing Road; Civic and Xinyi show the same pattern). VI-B Ablation Study We quantitatively evaluate the individual contribution of each functional module within HLSR under the 80008000-vehicle traffic scenario with SUMO seed 4242. TABLE I summarizes the mean travel‑time and average reroutes‑per‑vehicle metrics, with all results reported relative to the full recommended HLSR configuration (θur=9 _ur=9, Rank‑enhanced forecasting). Block I performs leave‑one‑component‑out ablation, where one controller module is removed or modified in each trial. Block I keeps the full HLSR control pipeline intact and only replaces the Phase‑3 travel‑time forecaster VpredV^pred. A positive value of Δ indicates degraded performance, i.e., a higher mean travel time compared with the baseline HLSR. TABLE I: Ablation study on the 80008000-vehicle Tainan scenario under SUMO seed 4242. Block I varies one controller component; Block I varies only the Phase‑3 forecaster. Differences are relative to recommended HLSR (Rank forecasting; positive == worse). Travel time Reroutes per vehicle Configuration mean (s) Δ vs HLSR mean Δ vs HLSR Block I: HLSR‑anchored component ablation HLSR 380.6 — 0.61 — HLSR w/o RVR_V (EC1) 400.3 +19.7+19.7 0.45 −0.16-0.16 HLSR‑fixed θ (EC2) 385.7 +5.1+5.1 0.49 −0.12-0.12 HLSR‑LIVE (EC3) 438.1 +57.5+57.5 0.80 +0.19+0.19 HLSR‑time (EC4) 405.6 +25.0+25.0 0.56 −0.05-0.05 HLSR‑noDB 393.0 +12.4+12.4 0.51 −0.10-0.10 Block I: forecaster ablation on the HLSR stack HLSR‑LSTM (per‑edge) 388.2 +7.6+7.6 0.49 −0.12-0.12 HLSR‑Huber 400.8 +20.2+20.2 0.56 −0.05-0.05 VI-B1 HLSR Component Ablation Disabling the hybrid live–forecast costing mechanism yields the largest performance degradation in Block I, corresponding to the HLSR‑LIVE case with a +57.5+57.5 s travel‑time penalty. Since the set of candidate rerouting vehicles remains identical across this comparison, this performance gap originates from the Phase‑3 speed fusion logic rather than the upstream vehicle‑selection module. Time‑exclusive cost scoring (HLSR‑time) and occupancy‑only congestion detection (HLSR w/o RVR_V) increase mean travel time by 25.025.0 s and 19.719.7 s, respectively. These observations demonstrate that both multi‑objective cost allocation and the velocity‑ratio congestion threshold bring tangible benefits once hybrid costing is enabled. Removing driver‑behavior personalization (HLSR‑noDB) incurs a moderate yet consistent penalty of 12.412.4 s. Reducing the upstream hop depth from θur=9 _ur=9 to θur=4 _ur=4 (HLSR‑fixed θ) raises the mean travel time to 385.7385.7 s (+5.1+5.1 s), which aligns with the flat performance plateau observed in Fig. 6. VI-B2 Forecaster Comparison Block I isolates the impact of different Phase‑3 prediction backbones while preserving the complete HLSR control framework. HLSR‑LSTM adopts a per‑edge LSTM predictor. HLSR‑Huber utilizes the network‑level LSTAN_GERPE backbone introduced in Sec. IV-C, but omits path‑ranking fine‑tuning. By contrast, the recommended HLSR employs the identical backbone enhanced with OD‑aware k‑shortest‑path ranking loss described in Sec. IV-C3. Compared against the baseline HLSR (380.6380.6 s), HLSR‑LSTM and HLSR‑Huber degrade by 7.67.6 s and 20.220.2 s, respectively. This result validates that ranking‑aware fine‑tuning constitutes the preferred output‑head configuration for the network‑level forecaster; meanwhile, the per‑edge LSTM achieves substantially better performance than the Huber‑only variant. Nevertheless, the performance gaps introduced by different forecasting backbones are smaller than the large penalty observed for HLSR‑LIVE. This confirms that hybrid live‑forecast costing serves as the primary source of overall performance improvement. VI-C Baseline Routing Comparison We compare recommended HLSR with competing rerouting methods under the same seed 4242 protocol, extending the 80008000-vehicle setting of TABLE I to 1600016000 and 2000020000 vehicles. TABLE I reports mean travel duration and reroutes per vehicle; each cell is one complete trial on a fixed demand file. The compared methods are partially reimplemented on our TraCI platform while preserving the core selection and costing mechanisms documented in the source papers. 1. NRR [15]: congestion is indicated by road occupancy, upstream depth is fixed at θur=1 _ur=1, and multi-factor next-edge costs determine the immediate successor segment. 2. ReFOCUS+ [12]: congestion is declared from averaged occupancy and velocity scores, upstream depth is fixed at θur=3 _ur=3, and Shannon-entropy routing is executed under traffic-management-center control. 3. Du-GAQ [6]: fog-cloud GAQ region indices with entropy-balanced k-shortest-path (EBkSP) assignment (Priority-Near; Tainan-adapted GAQ checkpoint). 4. HLSR-Rank (classic selective): an earlier selective checkpoint that uses Rank forecasts without the full recommended OPT control stack. 5. HLSR-LIVE: the candidate vehicle set of HLSR is retained, whereas Phase-3 costing uses live speeds only. 6. CAIE-T-Scoped [17]: live travel-time Dijkstra is applied exclusively to the same selective candidate set. 7. CAIE-T [17]: live travel-time Dijkstra is applied to essentially all on-road vehicles every decision period, thereby embodying a stronger network-wide deployment assumption. These baselines therefore span classical and region-based selective rerouting (NRR, ReFOCUS+, Du-GAQ, HLSR-Rank), live-only control on the HLSR candidate set (HLSR-LIVE, CAIE-T-Scoped), and network-wide live travel-time Dijkstra (CAIE-T). HLSR-LIVE is both the Block I ablation of hybrid costing and the fair-scope live baseline in this comparison. TABLE I: Baseline comparison across demand levels (SUMO seed 4242). Entries report mean travel duration (s) and mean reroutes per vehicle (R). HLSR denotes the recommended hybrid selective configuration. At 80008000 vehicles, HLSR also attains time loss 215.5215.5 s and waiting time 150.1150.1 s (lowest among compared methods). 8000 16000 20000 Method Scope Dur. R Dur. R Dur. R NRR θur=1 _ur=1 525.5 0.36 1211.5 1.36 1276.9 1.42 ReFOCUS+ θur=3 _ur=3 632.1 0.84 1079.8 1.96 1151.5 2.20 HLSR-Rank (classic selective) selective 609.7 0.68 1113.7 1.57 1102.4 1.58 Du-GAQ GAQ+EBkSP 425.5 0.64 1384.4 3.84 1463.1 4.09 HLSR-LIVE OPT selection 438.1 0.80 1281.3 6.36 1410.0 7.26 CAIE-T all vehicles 408.1 0.48 1013.9 2.30 1180.0 2.74 CAIE-T-Scoped OPT selection 391.6 0.35 1011.6 2.53 1120.3 2.84 HLSR OPT selection 380.6 0.61 895.7 3.62 971.7 4.06 Travel-Time and Scope Analysis. At 80008000 vehicles, we first hold the OPT candidate set fixed. HLSR attains 380.6380.6 s, improving upon HLSR-LIVE (438.1438.1 s) by 57.557.5 s and upon CAIE-T-Scoped (391.6391.6 s) by 11.011.0 s. Hybrid forecast information is therefore beneficial when vehicle selection and live sensing are aligned. Network-wide CAIE-T remains slower (408.1408.1 s) despite replanning far more vehicles, so a larger intervention set does not replace hybrid costing. Among the remaining selective methods, Du-GAQ is the strongest at this demand (425.5425.5 s) yet still trails HLSR by 44.944.9 s, while NRR, ReFOCUS+, and HLSR-Rank remain above 525525 s. HLSR also attains the lowest time loss (215.5215.5 s) and waiting time (150.1150.1 s) among the compared methods. Multi-Demand Comparison. Mean travel times increase with demand, yet HLSR remains best at every level in TABLE I (895.7895.7 s / 971.7971.7 s at 1600016000 / 2000020000 vehicles). The same-scope gaps widen: CAIE-T-Scoped trails by 115.9115.9 s and 148.6148.6 s, and HLSR-LIVE degrades to 1281.31281.3 s / 1410.01410.0 s with reroute rates of 6.366.36 / 7.267.26. Du-GAQ, which was competitive at 80008000 vehicles, likewise degrades to 1384.41384.4 s / 1463.11463.1 s (gaps of 488.7488.7 s / 491.4491.4 s). NRR, ReFOCUS+, and HLSR-Rank remain substantially slower at both higher demands, and network-wide CAIE-T still trails HLSR (1013.91013.9 s / 1180.01180.0 s). Relative to the 80008000-vehicle no-reroute floor (NONE, 1387.11387.1 s), HLSR reduces mean travel time by 72.6%72.6\% while keeping mean reroutes well below the LIVE extreme. VI-D Discussion Results in TABLES I and I indicate that HLSR’s travel‑time reduction arises from coupled multi‑module contributions instead of one dominant component. Fixing the OPT candidate set, disabling hybrid live–forecast costing (HLSR‑LIVE) produces the largest penalty (+57.5+57.5 s) and yields inferior performance across all demand levels. HLSR outperforms CAIE‑T‑Scoped by 11.011.0 s at 80008000 vehicles and surpasses network‑wide CAIE‑T despite operating with a much smaller rerouting set, verifying that Phase‑3 live‑forecast fusion serves as the primary performance driver. Under hybrid costing, other components contribute in descending order: time‑only scoring (+25.0+25.0 s), occupancy‑only detection (+19.7+19.7 s), disabled driver personalization (+12.4+12.4 s), and shallower upstream depth θur=4 _ur=4 (+5.1+5.1 s). Block I demonstrates that ranking‑aware forecasting is preferred; the performance gaps from HLSR‑LSTM (+7.6+7.6 s) and HLSR‑Huber (+20.2+20.2 s) are both smaller than the HLSR‑LIVE penalty. Therefore, the forecaster supports hybrid‑cost calculation rather than replacing the rerouting controller. HLSR retains state‑of‑the‑art performance at 1600016000 and 2000020000 vehicles (895.7895.7 s, 971.7971.7 s). Baseline gaps widen under heavy congestion, where HLSR‑LIVE suffers severe over‑rerouting. Classical selective approaches remain slower, and Du‑GAQ does not scale well to high‑demand cases. In summary, HLSR (θur=9 _ur=9, Rank forecasting) yields consistent travel‑time gains over competing baselines without excessive replanning overhead. VII Conclusion This paper presents HLSR, a selective hybrid live–forecast vehicle rerouting framework designed for real‑time urban congestion mitigation. In contrast to network‑wide live shortest‑path rerouting schemes that recompute routes for nearly all in‑traffic vehicles at every decision step, HLSR constrains rerouting interventions to only congestion‑affected vehicles. It computes alternative routes by fusing real‑time link‑level speed observations with short‑horizon traffic forecasts. The proposed framework integrates four key functional components: dual‑threshold occupancy‑velocity congestion detection, calibrated upstream hop depth together with approaching‑vehicle expansion, travel‑time‑weighted k-shortest‑path candidate generation, and horizon‑adaptive hybrid costing for multi‑objective route allocation. A network‑level spatio‑temporal forecaster provides the predicted speed outputs VpredV^pred for the hybrid‑cost computation; importantly, this forecasting module serves purely as a supporting component rather than functioning as a standalone end‑to‑end rerouting solution. Evaluated on the reproduced Tainan SUMO simulation testbed, the recommended HLSR configuration achieves lower mean travel time compared with fair‑scope live‑only baselines, and outperforms network‑wide live Dijkstra while operating with a considerably smaller set of rerouted vehicles. Ablation‑study results demonstrate that hybrid live–forecast costing contributes the major portion of performance improvement, while the specific choice of the prediction backbone for VpredV^pred plays a secondary supporting role. This performance hierarchy holds consistently under elevated traffic demand: HLSR maintains the best overall performance across all evaluated load levels, with growing performance margins against same‑scope live‑only approaches, which suffer from severe over‑rerouting under heavy congestion. References [1] H. Akaike (1998) Information theory and an extension of the maximum likelihood principle. In Selected papers of hirotugu akaike, p. 199–213. Cited by: §IV-D2. [2] C. Backfrieder, G. Ostermayer, and C. F. Mecklenbräuker (2017) Increased traffic flow through node-based bottleneck prediction and v2x communication. IEEE Transactions on Intelligent Transportation Systems 18 (2), p. 349–363. External Links: Document Cited by: §I-B. [3] M. Behrisch, L. Bieker, J. Erdmann, and D. Krajzewicz (2011) SUMO – simulation of urban mobility: an overview. In SIMUL 2011, S. &. U. of Oslo Aida Omerovic, R. I. -. R. T. P. D. A. Simoni, and R. I. -. R. T. P. G. Bobashev (Eds.), External Links: Link Cited by: §VI-A1. [4] Z. Cao, S. Jiang, J. Zhang, and H. Guo (2017) A unified framework for vehicle rerouting and traffic light control to reduce traffic congestion. IEEE Transactions on Intelligent Transportation Systems 18 (7), p. 1958–1973. External Links: Document Cited by: §I-B. [5] A. M. de Souza, R. S. Yokoyama, L. C. Botega, R. I. Meneguette, and L. A. Villas (2015) Scorpion: a solution using cooperative rerouting to prevent congestion and improve traffic condition. In 2015 IEEE International Conference on Computer and Information Technology; Ubiquitous Computing and Communications; Dependable, Autonomic and Secure Computing; Pervasive Intelligence and Computing, Vol. , p. 497–503. External Links: Document Cited by: §I-B. [6] R. Du, S. Chen, J. Dong, T. Chen, X. Fu, and S. Labi (2024) Dynamic urban traffic rerouting with fog-cloud reinforcement learning. Computer-Aided Civil and Infrastructure Engineering 39 (6), p. 793–813. External Links: Document Cited by: §I-C, item 3. [7] Google maps [online]. Note: Available at https://w.google.com/mobile/maps/ Cited by: §I. [8] D. Krajzewicz, J. Erdmann, M. Behrisch, and L. Bieker (2012) Recent development and applications of sumo-simulation of urban mobility. International journal on advances in systems and measurements 5 (3&4). Cited by: §VI-A1. [9] M. Milojevic and V. Rakocevic (2013) Short paper: distributed vehicular traffic congestion detection algorithm for urban environments. In 2013 IEEE Vehicular Networking Conference, Vol. , p. 182–185. External Links: Document Cited by: §I-A. [10] U. Nations (2014) World urbanization prospects. United Nations. External Links: Link Cited by: §I. [11] J. Pan, M. A. Khan, I. S. Popa, K. Zeitouni, and C. Borcea (2012) Proactive vehicle re-routing strategies for congestion avoidance. In 2012 IEEE 8th International Conference on Distributed Computing in Sensor Systems, p. 265–272. Cited by: §I-A. [12] M. Rezaei, H. Noori, M. Mohammadkhani Razlighi, and M. Nickray (2021) ReFOCUS+: multi-layers real-time intelligent route guidance system with congestion detection and avoidance. IEEE Transactions on Intelligent Transportation Systems 22 (1), p. 50–63. External Links: Document Cited by: §I-A, §I-C, item 2. [13] M. Rezaei, H. Noori, D. Rahbari, and M. Nickray (2017) ReFOCUS: a hybrid fog-cloud based intelligent traffic re-routing system. In 2017 IEEE 4th International Conference on Knowledge-Based Engineering and Innovation (KBEI), Vol. , p. 0992–0998. External Links: Document Cited by: §I-B. [14] TomTom [online]. Note: Available at https://w.tomtom.com/ Cited by: §I. [15] S. Wang, S. Djahel, Z. Zhang, and J. McManis (2016) Next road rerouting: a multiagent system for mitigating unexpected urban traffic congestion. IEEE Transactions on Intelligent Transportation Systems 17 (10), p. 2888–2899. External Links: Document Cited by: §I-B, §I-C, item 1. [16] X. Wang and S. Yang (2025) Lightweight spatio-temporal attention network with graph embedding and rotational position encoding for traffic forecasting. In 2025 IEEE International Conference on Service Operations and Logistics, and Informatics (SOLI), p. 1–6. External Links: Document Cited by: §IV-C2, §IV-C2, §IV-C3, §IV-C3, TABLE I, TABLE I, TABLE I, §IV, §VI-A3. [17] D. Wlodarczyk and T. Saber (2026) UAV-assisted traffic rerouting in disaster scenarios via grammar-guided genetic programming: effects of limited smart-vehicle adoption and cross-segment generalization. Computers & Industrial Engineering 215, p. 111839. External Links: Document Cited by: item 6, item 7. [18] S. Yang, Y. Su, Y. Chang, and H. Hung (2019) Short-term traffic prediction for edge computing-enhanced autonomous and connected cars. IEEE Transactions on Vehicular Technology 68 (4), p. 3140–3153. External Links: Document Cited by: §I-E, §IV-B1. [19] J. Y. Yen (1971) Finding the k shortest loopless paths in a network. Management Science 17 (11), p. 712–716. External Links: ISSN 00251909, 15265501, Link Cited by: §IV-C3, §V-C2. -A Notation List longtblr [ caption = Notations (editing reference; remove before submission), entry = Notations, label = Fig: notation, ] colspec = —X[1.15,l]—X[2.7,l]—, hlines, rowhead = 1, rowfoot = 0, row1 = font=, Symbol Description LsdL_sd Safe distance between two consecutive vehicles. Lrs(s)L_rs(s) Length of road segment s. L¯v L_v Average vehicle length. NcrN_cr Maximum number of candidate shortest routes per replanned vehicle. NrsN_rs Number of road segments in city zone zpz_p (equal-count WLOG). Nv(s,τ)N_v(s,τ) Number of vehicles on segment s at time τ. Nvmax(s)N_v^max(s) Capacity of segment s (vehicles). Nl(s)N_l(s) Number of lanes on segment s. NzN_z Number of city zones. RO(s,τ)R_O(s,τ) Road occupancy ratio on s at τ (1). RV(s,τ)R_V(s,τ) Road velocity ratio on s at τ (3). RS(s,τ)R_S(s,τ) Congestion severity of s at τ (19). rk(vr,τ)r_k(v_r,τ) k-th candidate route for rerouted vehicle vrv_r at τ. ∥rk∥ r_k Number of segments on candidate route rkr_k. r^(vr,τ) r(v_r,τ) Selected alternative route for vrv_r at τ (29). sp(q)s_p^(q) q-th road segment of city zone zpz_p. sk(j)(vr,τ)s_k^(j)(v_r,τ) j-th segment on candidate route rk(vr,τ)r_k(v_r,τ). Sur(i)(sc,τ)S_ur^(i)(s_c,τ) Set of i-hop upstream segments of congested segment scs_c. SurT(sc,τ)S_ur^T(s_c,τ) Union of upstream layers 1,…,θur1,…, _ur for scs_c (21). SrvT(sc,τ)S_rv^T(s_c,τ) Vehicles selected for rerouting w.r.t. scs_c (22). Scr(vr,τ)S_cr(v_r,τ) Set of NcrN_cr candidate routes for vrv_r. V¯(s,τ) V(s,τ) Mean speed on segment s at τ. V^(s,τ,vr) V(s,τ,v_r) Driver-tailored predicted average velocity of vrv_r on s. Vlim(s)V^lim(s) Speed limit on segment s. zpz_p p-th city zone. δO _O, δV _V Occupancy / velocity-ratio thresholds for dual-threshold TCD. Ψro _ro Weight of ROR_O in severity RSR_S (19). θur _ur Upstream hop depth for vehicle selection (recommended θur=9 _ur=9). V~(s,τ,h) V(s,τ,h) Hybrid live–forecast speed at horizon h (23). Vlive(s,τ)V^live(s,τ), Vpred(s,τ,h)V^pred(s,τ,h) Live and predicted segment speeds in (23). α(h)α(h) Live-speed blending weight at horizon h (24). α0 _0, αΔ _ Intercept and per-horizon decay of α(h)α(h). tin(j)t_in^(j) Estimated entry time into the j-th edge of a candidate route (26). (τ)C(τ) Congested segment set at decision time τ (20). hjh_j Horizon index aligned with segment entry time (4, 25). C^tt,C^d,C^s,C^o C^t, C^d, C^s, C^o Min–max normalized multi-cost terms in (29). SˇrvT(τ) S_rv^T(τ) Priority-sorted copy of SrvT(τ)S_rv^T(τ) for sequential ARA. S Full set of road segments. T, ToutT_out Aggregation period; forecast horizon length. Bd(vr,s)Bd(v_r,s), Δ , ηs _s, zmaxsz_ ^s, zminsz_ ^s Driver-behavior parameter and calibration factors (Sec. IV-D). VA(⋅)V_A(·) Driver-tailored segment speed; realized as V V in (17). Crtt(rk)C_r^t(r_k) Fused travel-time cost of candidate rkr_k (28). τX_τ Network-wide history tensor of speed and occupancy over TinT_in steps. fθf_θ Network-level spatio-temporal forecaster (LSTAN_GERPE / Rank). ℒHuberL_Huber Backbone Huber speed-value loss. ℒod_kspL_od\_ksp OD–k-shortest-path pairwise ranking loss (10). T(P,V)T(P;V) Path travel time of candidate P under speeds V (8). λrank _rank Weight of ℒod_kspL_od\_ksp in Rank fine-tuning. Approaching route-hop budget Fixed near-horizon budget (default 2) for route-based complement to θur _ur. wt,wd,ws,wow_t,w_d,w_s,w_o Multi-cost weights for travel time, distance, similarity, occupancy. CrT(⋅)C^T_r(·) [obsolete] Old total-route cost; use CrttC_r^t / (29). LrsmaxL_rs^max, LrsminL_rs^min [obsolete] Longest/shortest segment lengths; unused. RL(s)R_L(s) [obsolete] Normalized segment length; unused. ROz(z(s),τ)R^z_O(z(s),τ) [obsolete] Zone occupancy ratio; unused. Ψcr(s,τ) _cr(s,τ) [obsolete] Old K-SP edge weight; use (27).