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

1

HLSR: Hybrid Live–Forecast Selective Dynamic Vehicle Rerouting for Real-Time Congestion Avoidance Xiao Wang, Shun-Ren Yang, Member, IEEE, and Hui-Nien Hung

arXiv:2608.18056v1 [cs.AI] 18 Aug 2026

Abstract—Urban traffic congestion reduces productivity and increases travel cost and emissions. Network-wide live traveltime 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 horizondependent hybrid live–forecast segment speed used in multicost route allocation. On a reproduced Tainan SUMO scenario (seed 42), HLSR reduces mean travel time to 380.6 s at 8000 vehicles, outperforming same-scope live-only controls (438.1 s selective live; 391.6 s scoped live Dijkstra) and remaining competitive with network-wide live travel-time Dijkstra (408.1 s), while intervening on far fewer vehicles than a full-network policy; under the same protocol at 16000 and 20000 vehicles, HLSR remains best at 895.7 s and 971.7 s. Index Terms—Traffic congestion detection, selective vehicle rerouting, hybrid live–forecast routing, travel-time prediction, SUMO

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 II reviews representative prior work along these three dimensions. To address these gaps, we introduce HLSR (Hybrid Live–Forecast Selective Rerouting), a selective congestionalleviation 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 approachingvehicle expansion so that rerouting remains limited to congestion-related vehicles. In the primary setting at 8000 vehicles, this selective stack reduces mean travel time from 664.2 s (BC) to 438.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-timeweighted k-shortest-path generation plus multi-cost allocation. Under matched selective candidate scope, this hybrid costing further improves travel time from 438.1 s (HLSR-LIVE) to 380.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 42) at 8000, 16000, and 20000 vehicles, we compare HLSR against classical selective baselines (NRR, ReFOCUS+), the reimplemented DuGAQ method, a prior HLSR-Rank checkpoint, samescope live-only controls, and network-wide live travel•

I. I NTRODUCTION

The population gradually moves from rural areas to cities. A United Nations report [1] 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 [2] and Google Maps [3] 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 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). H. Hung is with the Institute of Statistics, National Chiao Tung University, Hsinchu, Taiwan (e-mail: hhung@stat.nctu.edu.tw).

time Dijkstra, reporting travel time, time loss, waiting time, route length, and reroute count. The remainder of this paper is organized as follows. Section II reviews prior rerouting methods by phase. Section III formalizes the system model and sensing quantities. Section IV details the travel-time prediction module that supplies multihorizon predicted segment speeds V 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.

are widely adopted. [10] scores routes from current real-time network states, whereas [6] combines roadside-unit and trafficmanagement-center data through a Shannon-entropy router. Learning-based alternatives similarly emphasize live or regionlevel indices. For example, [12] 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, (ii) calibrated upstream and approaching-vehicle selection under bounded intervention, and (iii) 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.

II. R ELATED W ORK 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. A. Congestion Detection Proactive rerouting systems must declare congestion before downstream queues fully form. [4] couples detection with rerouting but relies on a single traffic-density indicator, which is insufficient when occupancy and speed diverge. [5] performs distributed detection through V2V cooperation, yet its singlevehicle velocity assumption and local neighborhood scope limit network-wide consistency. [6] combines segment-level and zone-level real-time scores, but aggregated indicators can still misclassify localized or transient congestion. Dualthreshold designs that jointly monitor occupancy and velocity, together with severity-aware triggers, are therefore preferable for selective intervention.

III. S YSTEM M ODEL 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. 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 Nz city zones {z1 , z2 , . . . , zNz }. Without loss of generality, zone zp contains (N ) (1) Nrs road segments denoted {sp , . . . , sp rs }. Each segment s is characterized by length Lrs (s), lane count Nl (s), and speed limit V lim (s). Vehicles v report locations and destinations to the platform. τ denotes wall-clock time at a decision instant. The candidate-route budget Ncr is the maximum number of alternative paths retained for each replanned vehicle (default Ncr =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.

B. Rerouted-Vehicle Selection Once congestion is detected, the controller must decide which vehicles to replan without flooding the network with unnecessary route changes. [7] weights all segments by congestion degree and greedily steers vehicles toward locally minimal-cost edges, which can inflate path length and shift congestion elsewhere. [8] 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. [9] jointly optimizes rerouting and signal control but fixes the window size a priori; [10] broadcasts alarms through intelligent traffic lights with a fixed-level range; and [11] 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 approachingvehicle expansion.

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. In this architecture, roadside units periodically collect vehicle locations and destinations, while closed-circuit televisions and velocity / loop detectors export per-segment occupancy and

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

2026/8/19

2

values V pred (s, τ, h) are a multi-horizon forecast on s at horizon index h=1, . . . , Tout , where Tout 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 V live and V 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. E. Travel-Time Components When a vehicle vr is scored on a candidate route (1) (∥r ∥) rk (vr , τ ) = {sk → · · · → sk k }, where ∥rk ∥ denotes the number of segments on rk , the segment travel time (j) tv (sk (vr , τ )) decomposes into traffic-light queueing delay tq and road-segment passing time tp . The queueing model follows our earlier traffic-light formulation [13]. The passing time is obtained from a (hybrid) segment speed and, when enabled, a driver-tailored correction. Sec. IV specifies how V 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.

Fig. 1: Activity diagram of the traffic rerouting system.

mean-speed traces. Location and destination reports allow the platform to maintain the vehicle count Nv (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.

IV. T RAVEL T IME P REDICTION This section specifies the travel-time prediction module that supplies multi-horizon predicted speed values 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. III, we adopt our previously published spatio-temporal forecaster LSTAN_GERPE [14] 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.

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, τ ) denote the number of vehicles on segment s at time τ . The road occupancy ratio is defined as Nv (s, τ ) , Nvmax (s)

(1)

Lrs (s) × Nl (s), L̄v + Lsd

(2)

RO (s, τ ) = where the segment capacity is Nvmax (s) =

with average vehicle length L̄v and safe spacing Lsd . The road velocity ratio is likewise defined as RV (s, τ ) =

V̄ (s, τ ) , V lim (s)

(3)

where 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 =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, RO and RV furnish the measurable congestion state against which threshold-based detection operates, whereas route allocation itself is driven by the speed values introduced next.

A. Forecasting Design (j)

On forecasting vr ’s travel time tv (sk (vr , τ )) over segment (j) sk (vr , τ ) at a desired instant τ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 tv for a specific vehicle vr , 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:

D. Live and Predicted Speed Values At decision time τ , live and predicted speed values are available for costing candidate routes. The live speed value V live (s, τ ) is the current mean speed on segment s obtained from live sensing (TraCI / detectors). The predicted speed

2026/8/19

3

where T is the aggregation period of Sec. III and [·]+ clips negative values to zero. Our framework (j) forecasts tp (sk (vr , τ )) as follows: 1) the network-level (j) forecaster supplies V pred (sk , τ, hj ); 2) the drivertailored model maps this speed to vr ’s average velocity (j) (j) VA (sk (vr , τ ), τ(j) , Bd(vr , sk )) using the behavior parameter Bd introduced above; 3) finally, (j)

Lrs (sk (vr , τ ))

(j)

tp (sk (vr , τ )) = Fig. 2: Travel time component elements

(j)

.

The network-level forecaster and the driver-tailored model are elaborated in the following subsections.

1) 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 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. 2) Driver-tailored segment average velocity: Given the (j) network-level prediction for segment sk (vr , τ ), a driverbehavior model maps the predicted speed into a vehiclespecific average velocity VA (·) using the driver’s behavior parameter Bd(vr , s) and a calibrated factor ∆. Together with (j) a traffic-light delay model, this yields tv (sk (vr , τ )). The resulting personalized speed is consumed as the forecast branch of hybrid costing and does not replace live sensing for near-horizon segments.

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. 1) Network-Wide Speed-Value Formulation: Let S denote the set of road segments as in Sec. III, corresponding to nodes in the directed road graph, and N = |S| be its cardinality. At decision instant τ , measurements collected from loop detectors construct a historical input tensor  Xτ = x(s, τ − i) s∈S, i=0,...,T −1 ∈ RTin ×N ×F , (5) in

where the input time window Tin = 12 (one-minute time steps), and feature dimension F = 2 stacks mean speed and occupancy. The forecasting model fθ projects Xτ toward multi-horizon segment-wise speed predictions:
V pred (s, τ, h) = fθ Xτ ; Llap s,h , h = 1, . . . , Tout , (6)

B. The Prediction Framework Given the current time τ as the entering time into the candidate shortest route rk (vr , τ ), our framework operates iteratively as follows: provided with the estimated entering (j) time τj into the road segment sk (vr , τ ) obtained in the (j − 1)-th iteration, our framework predicts the travel time (j) (j) tv (sk (vr , τ )) over sk (vr , τ ) and the entering time τj+1 into (j+1) the next road segment sk (vr , τ ) in the j-th iteration. Fig. 2 (j) illustrates the component elements of tv (sk (vr , τ )), which are further explained below. (j) 1) Traffic light queueing time tq (sk (vr , τ )): This represents the delay that vehicle vr should face at the entrance (j) intersection of sk (vr , τ ) due to a red traffic light upon the estimated entering time τ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 [13] to estimate the two time segments, based on the predefined traffic-light signal timing plans (from the government transportation department) and a probabilistic model, respectively. The readers are referred to [13] for the details. (j) 2) Road segment passing time tp (sk (vr , τ )): Let τ(j) be (j) τj + tq (sk (vr , τ )), representing the instant when vr leaves (j) the traffic light and starts to cross sk (vr , τ ). Let the horizon index aligned with τ(j) be   τ(j) − τ , (4) hj = T +

2026/8/19

(j)

VA (sk (vr , τ ), τ(j) , Bd(vr , sk ))

in which Tout = 6 defines the prediction horizon length, and Llap denotes Laplacian positional encoding derived from the road graph. During route assignment, 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. 2) LSTAN-GERPE Architecture: The network-level forecaster adopts our previously published LSTAN_GERPE model [14], 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 V pred (s, τ, h) for h = 1, . . . , Tout . Pretraining follows the same Huber regression objective as in our prior work [14]. Consequently, the edge-level Huber

4

TABLE I: Default hyperparameters of LSTAN_GERPE for speed–occupancy inputs, adopted from our prior work [14]. Parameter Input / output window (Tin , Tout ) Features F Embed / skip dimension Encoder depth D Geo / sem / temporal attention heads Geographic hop mask ∆far Training loss

∆T̂ = T̂ (Pi ) − T̂ (Pj ) denote its predicted counterpart. The pairwise logistic ranking penalty is formulated as 
 (9) ℓ(i, j) = log 1 + exp −sign(∆T ∗ ) ∆T̂ ,

Value 12, 6 speed, occupancy 64 / 256 6 4/2/2 7 Huber (δ = 2) [14]

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: XX 1 X 1 ℓh (i, j), (10) Lod ksp = |H| |O| |Qo |

loss LHuber 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 [14]. 3) 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 rankingaware variant denoted LSTAN_GERPE_rank. During finetuning, the encoder of our pretrained LSTAN_GERPE [14] is kept frozen; only the prediction output head is adapted via an OD-based k-shortest-path ranking loss. The composite training objective reads L = LHuber + λrank Lod ksp ,

h∈H o∈O

where O is the collection of OD pairs within one mini-batch, Qo stands for the filtered valid path subset of Po , and H represents the set of prediction horizons for V pred . Since pairwise comparisons are constrained to k-shortest candidate paths sharing identical origin-destination pairs, Lod 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.

(7)

where LHuber denotes the original backbone Huber loss for speed-value regression inherited from our prior work [14], and λ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 Po = {Po,1 , . . . , Po,K } of K loop-free k-shortest paths [15] over the directed road graph, with K = Ncr matching the candidate-route budget defined in Sec. III. Given segment-wise speed values V , the travel time of a path P is computed by aggregating edge travel times: T (P ; V ) =

Lrs (e)
, max V (e), ε e∈P X

D. Driver-Tailored Segment Average Velocity 1) Assumption and definition: We take the assumption that we can get road segment s monitoring velocity and each vehicle vr historical traffic information like velocity, entry time and exit time. Single vehicle average velocity V̄ (s, τ, vr ) is calculated as equation 11, where tvrr (τx ) and tvrr (τy ) are the measured exit time and entry time of vehicle vr on road segment r from detailed traffic data, respectively. Lrs (s) is the length of road segment s. V̄ (s, τ, vr ) =

Lrs (s) tvrr (τx ) − tvrr (τ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) (Fig. 3). Behavior parameter Bd(vr , s) is calculated as equa-

(8)

where ε > 0 is a small positive constant for numerical stability. By substituting the predicted speed values V pred and ground-truth detector-measured speeds V ∗ into (8), we obtain predicted path travel times T̂ (P ) and ground-truth path travel times T ∗ (P ), respectively. Within each OD candidate set Po , we sample path pairs (Pi , Pj ). Only pairs whose ground-truth time difference exceeds a threshold tmin are retained, such that near-tie samples do not dominate gradient updates. Let ∆T ∗ = T ∗ (Pi ) − T ∗ (Pj ) denote the ground-truth travel-time difference and

2026/8/19

(i,j)∈Qo

Fig. 3: Definition of the driver behavior parameter

5

Calculate (Bd)ηs and compress it in the x-direction by multiplying (zmax − zmin ) to match the shape of F (z s ), then shift right by adding zmin . As mentioned above, let V̂ (s, τ, vr ) (equivalently VA ) be the predicted average velocity of vehicle vr on segment s at time τ , Bd the driver behavior parameter, and V (s, τ ) the network-level segment speed (predicted speed values or live observation). The relationship between average velocity and segment speed is then

tion 12. Bd(vr , s) =

¯ (s, vr ) − Vhis ¯ (s, vN ) Vhis ¯ ¯ (s, vN ) Vhis (s, vM ) − Vhis

(12)

¯ (s, vr ) which is a Min-Max-Scaler normalization, where Vhis ¯ is historical average velocity of vr , Vhis (s, vM ) is historical average velocity of vehicle vM with the maximum historical ¯ (s, vN ) is historical average velocity of all vehicles, Vhis average velocity of vehicle vN with the minimum historical average velocity of all vehicles. The relationship between single vehicle average velocity V̄ (s, τ, vr ) and the network-level (predicted or live) segment speed V (s, τ ) is expressed in equation 13. V̄ (s, τ, vr ) = V (s, τ ) × ∆

s s s V̂ (s, τ, vr ) =V (s, τ ) × [(zmax − zmin ) × (Bd)ηs + zmin ]

=V (s, τ ) × ∆ (17) with s s s ]. ∆ = [(zmax − zmin ) × (Bd)ηs + zmin

(13)

Empirical agreement between F (z) and F (∆), together with the calibrated (zmin , zmax , η) values, is verified in the experimental evaluation. 3) 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 (j) rk (vr , τ ). For each segment sk on the route, the forecaster (j) supplies V pred (sk , τ, hj ), the driver-tailored model yields (j) V̂ (sk (vr , τ ), τ ) via (17), and the segment time Lrs /V̂ is added to the route cost.

We define ∆ as driver-tailored factor which is correlated to per driver behavior parameter Bd(vr , s). 2) 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 )}, where ns 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 )}, where V (s, τ, vrns −1 ) is the instantaneous velocity at time τ for road segment s where vehicle vrns −1 is exactly on. we use zns s −1 V̄ (s,τ,v ns −1 ) stands for V (s,τ,vrns −1 ) , Next, we divide parallel elements in r ratio = {z0s , z1s , ...., zns s −1 }. Then, set V̄set and Vset , gaining Zset s we normalize zj (j ∈ [0, ns−1 ]) to zj∗s ∈ (0, 1) by linear transformation shown in equation 14, improving prediction efficiency. The prediction performance works better for cases in which ns is large enough. s zjs − zmin ns − 1 1 zj∗s = s × + , s zmax − zmin ns 2 × ns s zmax = max zjs , j=0,...ns −1

s zmin =

min

j=0,...ns −1

Algorithm 1: T C(fθ , Xτ , {Bd, η, zmax , zmin , Lrs }) Input : Forecaster fθ and history tensor Xτ ; (j) (j) (j) Per-segment parameters η(sk ), zmax (sk ), zmin (sk ), (j) (j) Bd(vr , sk ), Lrs (sk ) for j ∈ [1, ∥rk (vr , τ )∥]; Output : time cost CrV (rk (vr , τ )); Procedure : Compute the network-wide predicted speed values V pred (·, τ, ·) ← fθ (Xτ ; Llap ); V 2 Cr (rk (vr , τ )) = 0; 3 for j = 1; j <= ∥rk (vr , τ )∥; j + + do (j) (j) 4 V (sk , τ ) ← V pred (sk , τ, hj ); (j) 5 compute V̂ (sk (vr , τ ), τ ) using (17);

1

(14)

zjs

Next, we describe how we estimate ∆. We select fifty vehicles on each road segment and derive the related zjs (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 zjs values and nz the number of occurrences of that value, so that p(z s ) = nz /50. Because z s is discrete, its cumulative distribution function is X F (z s ) = p(z s ). (15)

6 7

CrV (rk (vr , τ )) = CrV (rk (vr , τ )) +

(j)

Lrs (sk (vr ,τ )) (j)

V̂ (sk (vr ,τ ),τ )

;

return CrV (rk (vr , τ ));

V. T HE P ROPOSED HLSR F RAMEWORK 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.

Z≤z s

Empirical CDFs of z s on detector segments are close to a power function. We therefore approximate F (z s ) by a parametric CDF of ∆ and estimate the power via maximum likelihood [16]: ns . (16) ηs = − Pj=ns −1 lnzj∗ j=0

2026/8/19

(18)

6

Live Sensing V live , RO , RV

Travel-Time Forecaster LSTAN-GERPE + Driver Model

Phase 1 Congestion Detection (TCD)

Algorithm 2: TCD: Dual-Threshold Traffic Congestion Detection Function Input : Target road segment s; Current timestamp τ ; Occupancy threshold δO ; Velocity ratio threshold δV ; Occupancy weight Ψro ; Output : Congestion flag isCongested; Congestion severity RS (s, τ ); Initialization: isCongested ← False; RS (s, τ ) ← 0; Procedure : Compute occupancy ratio RO (s, τ ) via (1) and (2); Compute velocity ratio RV (s, τ ) via (3); if RO (s, τ ) > δO ∧ (1 − RV (s, τ )) > δV then isCongested ← True; Calculate RS (s, τ ) using (19); return isCongested, RS (s, τ );

Predicted Speed V pred

Phase 2 Vehicle Selection (RVS)

Phase 3 Hybrid 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.

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. 1) 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 ; 4) Threshold of velocity ratio δV ; 5) Weight factor for occupancy-based congestion indicator Ψro . 2) Output Results: Two outputs are returned after execution: a binary flag isCongested indicating whether segment s is congested at time τ , and a continuous congestion severity metric RS (s, τ ). 3) Initialization Stage: Two internal variables are initialized before computation: isCongested is set to False, and the severity score RS (s, τ ) is initialized to 0. 4) Execution Procedure: First, the module calculates normalized occupancy RO (s, τ ) and normalized velocity ratio RV (s, τ ) using the formulas derived in Sec. III. Congestion is triggered only when both traffic metrics exceed their respective thresholds, i.e., RO (s, τ ) > δO and 1 − RV (s, τ ) > δV . Once the dual-threshold condition is satisfied, isCongested is assigned to True, and the composite congestion severity index is computed via: RS (s, τ ) = RO (s, τ ) · Ψro

+ 1 − RV (s, τ ) · 1 − Ψro .

(i)

3) Execution Procedure: We first define Sur (sc , τ ) as the set of i-hop upstream segments of sc at timestamp τ . These edges carry traffic flows that will enter sc in subsequent aggregation cycles. For illustrative purposes, Fig. 1 gives an (1) example: the 1-hop upstream set Sur (sc , τ ) = {s1 , s5 , s8 } (2) and the 2-hop upstream set Sur (sc , τ ) = {s3 , s6 , s12 , s13 }. Let θur denote the upstream hop depth, i.e., the maximum upstream layer considered for vehicle selection. A larger θur expands the intervention range but also raises the risk of overrerouting; the recommended deployment uses θur =9. The full upstream segment pool is the union of hop layers 1, . . . , θur : T Sur (sc , τ ) =

(i) Sur (sc , τ ).

(21)

i=1

(19)

The base candidate vehicle set consists of all vehicles residing T within Sur (sc , τ ) at timestamp τ :

Finally, the flag isCongested and severity value RS (s, τ ) are returned as function outputs. Collecting all congested segments at decision time τ yields the congested set  C(τ ) = (s, RS (s, τ )) s ∈ S, isCongested(s, τ ) . (20)

 T T Srv (sc , τ ) = vr vr is located on any segment s ∈ Sur (sc , τ ) at τ

( a) Approaching-Vehicle Expansion Mechanism: Upstream selection and approaching expansion play complementary roles. The hop budget θur sets a topology window T Sur (sc , τ ): 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 sc shortly along their planned routes. Concretely, a vehicle is added if (i) sc remains on its pre-planned route and (ii) the number of remaining route hops from its current edge to sc is at most two (a fixed near-horizon budget). The final rerouting set for sc 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.

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. 1) Input Parameters: Three inputs are required for the selection module: 1) Congested target segment sc ; 2) Current decision timestamp τ ; 3) Upstream hop depth θur . 2) Output Results: The module outputs a vehicle set T Srv (sc , τ ), which collects all vehicles assigned to rerouting for mitigating congestion on sc .

2026/8/19

θ[ ur

7

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 tin of the target segment:   tin − τ h= , (25) T +

Algorithm 3: RVS: Rerouted Vehicle Selection Function Input : Congested road segment sc ; Current decision timestamp τ ; Upstream hop depth θur ; Output : Aggregated rerouting vehicle set T Srv (sc , τ ) for segment sc ; Procedure: Aggregate full upstream segment pool T Sur (sc , τ ) using (21); Generate the base vehicle set from T Sur (sc , τ ) via (22); Expand with approaching vehicles outside that window whose remaining route hops to sc are in {1, 2}; Return the union, keeping the smaller hop index per vehicle for later sorting; T 1 return Srv (sc , τ );

where T is the aggregation cycle of Sec. III, 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. (1) When evaluating a candidate path rk (vr , τ ) = {sk → (2) ∥rk ∥ sk → · · · → sk }, we iteratively compute entry time and horizon for each segment along the path: 1. Initialize entry (1) time of the first segment tin ← τ ; 2. For subsequent segment (j) sk , update arrival timestamp: (j) (j−1) (j−1)
tin = tin + tv sk , (26)

C. Phase 3: Alternative Route Allocation

(j−1)

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. 1) Input Parameters: The allocation module accepts three mandatory inputs: 1. Current decisionStimestamp τ ; 2. AggreT T (τ ) = (sc ,RS )∈C(τ ) Srv (sc , τ ), gated rerouting vehicle set Srv merged from Phase 2 outputs over the congested set C(τ ) in (20); 3. Maximum number of candidate paths Ncr reserved for each individual vehicle. 2) Execution Procedure: For every vehicle requiring reroutT (τ ), the module generates Ncr feasible candiing within Srv date paths and selects the optimal route via multi-objective cost minimization based on horizon-adaptive fused travel speeds. a) Horizon-Adaptive Live–Forecast Speed Fusion: Let V live (s, τ ) denote real-time segment speed from roadside detectors, and 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:
Ṽ (s, τ, h) = α(h) V live (s, τ ) + 1 − α(h) V pred (s, τ, h). (23) The live-data weight α(h) decays linearly with prediction horizon index h, with intercept α0 and per-horizon decay α∆ :
α(h) = max 0, α0 − h · α∆ . (24)

where tv (sk ) stands for the fused segment travel time (including optional traffic-light queue delay introduced in the travel-time prediction module). The corresponding horizon hj (j) (j) for segment sk is obtained by substituting tin into (25), (j) which matches (4) when tin = τ(j) . Early route segments carry small hj with dominant live-speed weight, whereas downstream long-distance segments use forecast-heavy fused speeds, matching the “near real-time, far predictive” design principle. b) Travel-Time Weighted Candidate Generation: The T raw vehicle set Srv (τ ) is first reordered into prioritized T sequence Šrv (τ ) by (i) ascending upstream hop index and (ii) descending residual destination distance, so that vehicles near bottlenecks with long residual trips are updated first. We T (τ ) sequentially and construct the then process each vr ∈ Šrv candidate path set Scr (vr , τ ) = {rk (vr , τ ) | k = 1, 2, . . . , Ncr }. 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 Kshortest path algorithm [15] with dynamic travel-time edge weight Lrs (s) , (27) w(s, τ ) = Ṽ (s, τ, 0) using the fused speed Ṽ from (23) at the immediate horizon h=0. Unlike traditional length-weighted K-SP, this timeaware weighting scheme pushes fast, low-congestion corridors into the candidate pool before final multi-cost ranking. c) Multi-Objective Cost Allocation: Given candidate path rk (vr , τ ) with per-segment horizon hj , the fused traveltime cost is accumulated as:

For sufficiently large horizons satisfying h ≥ ⌈α0 /α∆ ⌉, α(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.

2026/8/19

∥rk ∥

Crtt (rk ) =

8

X

(j)

Lrs (sk )

(j) j=1 Ṽ (sk , τ, hj )

,

(28)

Algorithm 4: ARA: Adaptive Multi-Cost Alternative Route Allocation Function Input : Current decision timestamp τ ; T Aggregated rerouting vehicle set Srv (τ ); Maximum candidate route count Ncr ; T T Procedure: Šrv (τ ) ← Sort Srv (τ ) by ascending upstream hop index, then descending residual destination distance; T foreach vr ∈ Šrv (τ ) in sorted order do Generate candidate set Scr (vr , τ ) via travel-time weighted Yen K-SP using (27); Compute normalized multi-cost scores and select optimal path r̂(vr , τ ) via (23)–(29); Send rerouting command to vr for route r̂(vr , τ );

Algorithm 5: Main Runtime Loop of the Proposed HLSR Framework Input : The full set of road segments S; Occupancy threshold δO and velocity ratio threshold δV ; Congestion severity weighting factor Ψro ; Upstream hop depth θur ; Maximum number of candidate routes Ncr ; 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 then Aggregate window-wise traffic statistics over all s ∈ S; C(τ ) ← ∅; foreach s ∈ S do isCongested, RS (s, τ ) ← TCD(s, τ, δO , δV ); if isCongested then C(τ ) ← C(τ ) ∪ {(s, RS (s, τ ))};

with optional additive traffic light waiting delay. HLSR jointly optimizes four normalized cost dimensions: travel time C tt , path length C d , route similarity penalty C s , and network occupancy balance term C o . All four metrics are min–max normalized over the candidate set Scr (vr , τ ) to eliminate magnitude bias (denoted Ĉ tt , Ĉ d , Ĉ s , Ĉ o ), and the optimal route is selected via weighted minimization with nonnegative weights wt , wd , ws , wo :
r̂(vr , τ ) = arg min wt Ĉ tt + wd Ĉ d + ws Ĉ s + wo Ĉ o .

1

if C(τ ) ̸= ∅ then S T Srv (τ ) ← (sc ,RS )∈C(τ ) RVS(sc , τ, θur ); T ARA(τ, Srv (τ ), Ncr ) /* Trigger forecast inference */ ;

rk ∈Scr

(29) The recommended weight combination (wt , wd , ws , wo ) = (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 vr to switch to the optimal path r̂(vr , τ ).

VI. P ERFORMANCE E VALUATION This section evaluates the proposed HLSR framework. We first ablate individual components and forecasters on the 8000vehicle Tainan scenario, then compare HLSR with competing rerouting methods under 8000, 16000, and 20000 vehicles. A. Simulation Settings 1) Simulation Platform and Road Network: HLSR is implemented in Python and co-simulated with Eclipse SUMO 1.18 [17], [18] via the TraCI interface, where the models presented in Secs. III–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 204 intersections, 561 road segments, and 77.3 km of total roadway length. The network is further divided into 14 traffic-analysis zones (TAZs). Among them, five zones serve as traffic origins (Z4 , Z10 , Z12 , Z13 , Z14 ) and four act as destinations (Z2 , Z3 , Z6 , Z9 ), which together construct 20 unique origin–destination (OD) pairs, as visualized in Fig. 5. Vehicle travel demand is injected within a 7200 s simulation window and uniformly partitioned into four successive 1800 s intervals. Specifically, 25% of total vehicles are released in each time slot: [0, 1800), [1800, 3600), [3600, 5400), and [5400, 7200) s. Three traffic-demand scales, namely 8000,

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 realtime segment speed and occupancy measurements collected from roadside detectors. Selective rerouting is triggered at each aggregation-window boundary of duration T (Sec. III). Algorithm 5 assembles Phases 1–3: at τ = nT , TCD builds C(τ ) via (20); if nonempty, RVS unions per-bottleneck sets T into Srv (τ ), and ARA assigns hybrid live–forecast routes using V pred from Sec. IV. The algorithm takes inputs S, thresholds δO , δV , severity weight Ψro , upstream depth θur , candidate budget Ncr , and period T . After initialization, the main loop advances simulation time step-by-step. When τ = 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.

2026/8/19

9

Mean travel time Recommended ur = 9 Mean reroutes / vehicle

410 405

0.65 0.60

400

0.55

395

0.50

390

0.45

385 380

0.70 Mean reroutes / vehicle

415 Mean travel time (s)

16000, and 20000 vehicles, are evaluated on this fixed network topology. Each simulation trial runs until all generated vehicle trips are fully completed.

0.40 1

2

3

4 5 6 7 8 Upstream depth ur

9 10 11

Fig. 6: Upstream-depth sweep on the recommended HLSR stack (8000 vehicles, SUMO seed 42). The highlighted marker is θur =9.

Fig. 5: Fourteen TAZs on the Tainan testbed (origins Z4 , Z10 , Z12 , Z13 , Z14 ; destinations Z2 , Z3 , Z6 , Z9 ). 2) Evaluation Parameters: All experiments use SUMO seed 42 and aggregation period T =300 s. The candidateroute budget is Ncr =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), hybrid blending (α0 , α∆ )=(0.75, 0.12), multi-cost weights (wt , wd , ws , wo )=(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 m and Lsd =2.5 m. The remaining stack parameter is the upstream hop depth θur : a shallow window localizes intervention, whereas a deep window can over-reroute. Holding the settings above fixed, we sweep θur ∈ {1, . . . , 11} at 8000 vehicles (Fig. 6). Mean travel time is high at θur =1 and 2, then nearly flat for θur ∈ [3, 8] (384.4–390.5 s), while mean reroutes per vehicle increase almost monotonically. The minimum is at θur =9 (380.6 s), with θur =10 essentially tied (380.8 s); θur =11 rises to 388.0 s and the highest reroute rate (0.69). Subsequent HLSR rows in TABLES II–III therefore use θur =9. TABLE II also reports a shallower setting θur =4, which lies in the flat mid-range of Fig. 6 and is slightly worse. 3) Travel-Time Prediction Setup: The travel-time prediction module generates multi-horizon predicted speed outputs V 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.

2026/8/19

10

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 [14]. 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, minimum path travel-time threshold tmin =10 s, mini-batch size containing eight OD pairs (up to 32 candidate paths per OD pair), and learning rate 5×10−5 . A prototype per-edge LSTM model is preserved solely as an ablation baseline, corresponding to the HLSR-LSTM entry in TABLE II. 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 zjs validate the power-law formulation adopted for the driver-tailored factor ∆ in (18). Fig. 8 provides a representative CDF comparison between empirical F (z) and model-fitted F (∆) for Nanjing Road; Civic Street and Xinyi Street exhibit consistent fitting performance. B. Ablation Study We quantitatively evaluate the individual contribution of each functional module within HLSR under the 8000-vehicle traffic scenario with SUMO seed 42. TABLE II summarizes

duced 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.

1

Probability

0.8 0.6 0.4

C. Baseline Routing Comparison

0.2 00

z ∆ 0.5

1

1.5

2

2.5

3

Value

Fig. 8: Representative fit of model F (∆) to empirical F (z) (Nanjing Road; Civic and Xinyi show the same pattern).

the mean travel-time and average reroutes-per-vehicle metrics, with all results reported relative to the full recommended HLSR configuration (θ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 II keeps the full HLSR control pipeline intact and only replaces the Phase-3 travel-time forecaster V pred . A positive value of ∆ indicates degraded performance, i.e., a higher mean travel time compared with the baseline HLSR. 1) 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 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 RV ) increase mean travel time by 25.0 s and 19.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.4 s. Reducing the upstream hop depth from θur =9 to θur =4 (HLSR-fixed θ) raises the mean travel time to 385.7 s (+5.1 s), which aligns with the flat performance plateau observed in Fig. 6. 2) Forecaster Comparison: Block II 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.6 s), HLSR-LSTM and HLSR-Huber degrade by 7.6 s and 20.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 intro-

2026/8/19

11

We compare recommended HLSR with competing rerouting methods under the same seed 42 protocol, extending the 8000vehicle setting of TABLE II to 16000 and 20000 vehicles. TABLE III 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 [10]: congestion is indicated by road occupancy, upstream depth is fixed at θur = 1, and multi-factor next-edge costs determine the immediate successor segment. 2) ReFOCUS+ [6]: congestion is declared from averaged occupancy and velocity scores, upstream depth is fixed at θur = 3, and Shannon-entropy routing is executed under traffic-management-center control. 3) Du-GAQ [12]: 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-TT-Scoped [19]: live travel-time Dijkstra is applied exclusively to the same selective candidate set. 7) CAIE-TT [19]: 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-TT-Scoped), and network-wide live travel-time Dijkstra (CAIE-TT). HLSR-LIVE is both the Block I ablation of hybrid costing and the fair-scope live baseline in this comparison. a) Travel-Time and Scope Analysis.: At 8000 vehicles, we first hold the OPT candidate set fixed. HLSR attains 380.6 s, improving upon HLSR-LIVE (438.1 s) by 57.5 s and upon CAIE-TT-Scoped (391.6 s) by 11.0 s. Hybrid forecast information is therefore beneficial when vehicle selection and live sensing are aligned. Network-wide CAIE-TT remains slower (408.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.5 s) yet still trails HLSR by 44.9 s, while NRR, ReFOCUS+, and HLSR-Rank remain above 525 s. HLSR also attains the lowest time loss (215.5 s) and waiting time (150.1 s) among the compared methods. b) Multi-Demand Comparison.: Mean travel times increase with demand, yet HLSR remains best at every level in

TABLE II: Ablation study on the 8000-vehicle Tainan scenario under SUMO seed 42. Block I varies one controller component; Block II varies only the Phase-3 forecaster. Differences are relative to recommended HLSR (Rank forecasting; positive = worse). Travel time

mean

∆ vs HLSR

Block I: HLSR-anchored component ablation HLSR 380.6 — HLSR w/o RV (EC1) 400.3 +19.7 HLSR-fixed θ (EC2) 385.7 +5.1 HLSR-LIVE (EC3) 438.1 +57.5 HLSR-time (EC4) 405.6 +25.0 HLSR-noDB 393.0 +12.4

0.61 0.45 0.49 0.80 0.56 0.51

— −0.16 −0.12 +0.19 −0.05 −0.10

Block II: forecaster ablation on the HLSR stack HLSR-LSTM (per-edge) 388.2 +7.6 HLSR-Huber 400.8 +20.2

0.49 0.56

−0.12 −0.05

Configuration

∆ vs HLSR

Reroutes per vehicle

mean (s)

TABLE III: Baseline comparison across demand levels (SUMO seed 42). Entries report mean travel duration (s) and mean reroutes per vehicle (RR). HLSR denotes the recommended hybrid selective configuration. At 8000 vehicles, HLSR also attains time loss 215.5 s and waiting time 150.1 s (lowest among compared methods). Method NRR ReFOCUS+ HLSR-Rank (classic selective) Du-GAQ HLSR-LIVE CAIE-TT CAIE-TT-Scoped HLSR

8000 Dur. RR 525.5 0.36 632.1 0.84 609.7 0.68 425.5 0.64 438.1 0.80 408.1 0.48 391.6 0.35 380.6 0.61

Scope θur =1 θur =3 selective GAQ+EBkSP OPT selection all vehicles OPT selection OPT selection

TABLE III (895.7 s / 971.7 s at 16000 / 20000 vehicles). The same-scope gaps widen: CAIE-TT-Scoped trails by 115.9 s and 148.6 s, and HLSR-LIVE degrades to 1281.3 s / 1410.0 s with reroute rates of 6.36 / 7.26. Du-GAQ, which was competitive at 8000 vehicles, likewise degrades to 1384.4 s / 1463.1 s (gaps of 488.7 s / 491.4 s). NRR, ReFOCUS+, and HLSR-Rank remain substantially slower at both higher demands, and network-wide CAIE-TT still trails HLSR (1013.9 s / 1180.0 s). Relative to the 8000-vehicle no-reroute floor (NONE, 1387.1 s), HLSR reduces mean travel time by 72.6% while keeping mean reroutes well below the LIVE extreme.

16000 Dur. RR 1211.5 1.36 1079.8 1.96 1113.7 1.57 1384.4 3.84 1281.3 6.36 1013.9 2.30 1011.6 2.53 895.7 3.62

20000 Dur. RR 1276.9 1.42 1151.5 2.20 1102.4 1.58 1463.1 4.09 1410.0 7.26 1180.0 2.74 1120.3 2.84 971.7 4.06

the performance gaps from HLSR-LSTM (+7.6 s) and HLSR-Huber (+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 16000 and 20000 vehicles (895.7 s, 971.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, Rank forecasting) yields consistent travel-time gains over competing baselines without excessive replanning overhead.

D. Discussion Results in TABLES II and III 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 s) and yields inferior performance across all demand levels. HLSR outperforms CAIE-TT-Scoped by 11.0 s at 8000 vehicles and surpasses network-wide CAIE-TT 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 s), occupancy-only detection (+19.7 s), disabled driver personalization (+12.4 s), and shallower upstream depth θur =4 (+5.1 s). Block II demonstrates that ranking-aware forecasting is preferred;

2026/8/19

12

VII. C ONCLUSION 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 V 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 V 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. R EFERENCES [1] U. Nations, World Urbanization Prospects. United Nations, 2014. [2] “Tomtom [online].” Available at https://www.tomtom.com/. [3] “Google maps [online].” Available at https://www.google.com/mobile/ maps/. [4] J. Pan, M. A. Khan, I. S. Popa, K. Zeitouni, and C. Borcea, “Proactive vehicle re-routing strategies for congestion avoidance,” in 2012 IEEE 8th International Conference on Distributed Computing in Sensor Systems, pp. 265–272, IEEE, 2012. [5] M. Milojevic and V. Rakocevic, “Short paper: Distributed vehicular traffic congestion detection algorithm for urban environments,” in 2013 IEEE Vehicular Networking Conference, pp. 182–185, 2013. [6] M. Rezaei, H. Noori, M. Mohammadkhani Razlighi, and M. Nickray, “Refocus+: Multi-layers real-time intelligent route guidance system with congestion detection and avoidance,” IEEE Transactions on Intelligent Transportation Systems, vol. 22, no. 1, pp. 50–63, 2021. [7] A. M. de Souza, R. S. Yokoyama, L. C. Botega, R. I. Meneguette, and L. A. Villas, “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, pp. 497– 503, 2015. [8] C. Backfrieder, G. Ostermayer, and C. F. Mecklenbräuker, “Increased traffic flow through node-based bottleneck prediction and v2x communication,” IEEE Transactions on Intelligent Transportation Systems, vol. 18, no. 2, pp. 349–363, 2017. [9] Z. Cao, S. Jiang, J. Zhang, and H. Guo, “A unified framework for vehicle rerouting and traffic light control to reduce traffic congestion,” IEEE Transactions on Intelligent Transportation Systems, vol. 18, no. 7, pp. 1958–1973, 2017. [10] S. Wang, S. Djahel, Z. Zhang, and J. McManis, “Next road rerouting: A multiagent system for mitigating unexpected urban traffic congestion,” IEEE Transactions on Intelligent Transportation Systems, vol. 17, no. 10, pp. 2888–2899, 2016. [11] M. Rezaei, H. Noori, D. Rahbari, and M. Nickray, “Refocus: A hybrid fog-cloud based intelligent traffic re-routing system,” in 2017 IEEE 4th International Conference on Knowledge-Based Engineering and Innovation (KBEI), pp. 0992–0998, 2017. [12] R. Du, S. Chen, J. Dong, T. Chen, X. Fu, and S. Labi, “Dynamic urban traffic rerouting with fog-cloud reinforcement learning,” ComputerAided Civil and Infrastructure Engineering, vol. 39, no. 6, pp. 793–813, 2024. [13] S.-R. Yang, Y.-J. Su, Y.-Y. Chang, and H.-N. Hung, “Short-term traffic prediction for edge computing-enhanced autonomous and connected cars,” IEEE Transactions on Vehicular Technology, vol. 68, no. 4, pp. 3140–3153, 2019.

2026/8/19

13

[14] X. Wang and S.-R. Yang, “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), pp. 1–6, 2025. [15] J. Y. Yen, “Finding the k shortest loopless paths in a network,” Management Science, vol. 17, no. 11, pp. 712–716, 1971. [16] H. Akaike, “Information theory and an extension of the maximum likelihood principle,” in Selected papers of hirotugu akaike, pp. 199– 213, Springer, 1998. [17] M. Behrisch, L. Bieker, J. Erdmann, and D. Krajzewicz, “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.), ThinkMind, Oktober 2011. [18] D. Krajzewicz, J. Erdmann, M. Behrisch, and L. Bieker, “Recent development and applications of sumo-simulation of urban mobility,” International journal on advances in systems and measurements, vol. 5, no. 3&4, 2012. [19] D. Wlodarczyk and T. Saber, “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, vol. 215, p. 111839, 2026.

TABLE IV: Notations (editing reference; remove before submission) (Continued)

A PPENDIX A. Notation List

Symbol

Description

TABLE IV: Notations (editing reference; remove before submission)

δ O , δV

Occupancy / velocity-ratio thresholds for dual-threshold TCD.

Symbol

Description

Ψro

Weight of RO in severity RS (19).

Lsd

Safe distance between two consecutive vehicles.

θur

Upstream hop depth for vehicle selection (recommended θur =9).

Lrs (s)

Length of road segment s.

Ṽ (s, τ, h)

L̄v

Average vehicle length.

Hybrid live–forecast speed at horizon h (23).

Ncr

Maximum number of candidate shortest routes per replanned vehicle.

V live (s, τ ), V pred (s, τ, h)

Live and predicted segment speeds in (23).

Nrs

Number of road segments in city zone zp (equal-count WLOG).

α(h)

Live-speed blending weight at horizon h (24).

Nv (s, τ )

Number of vehicles on segment s at time τ .

α 0 , α∆

Intercept and per-horizon decay of α(h).

(j)

Nvmax (s)

Capacity of segment s (vehicles).

tin

Estimated entry time into the j-th edge of a candidate route (26).

Nl (s)

Number of lanes on segment s.

C(τ )

Nz

Number of city zones.

Congested segment set at decision time τ (20).

RO (s, τ )

Road occupancy ratio on s at τ (1).

hj

RV (s, τ )

Road velocity ratio on s at τ (3).

Horizon index aligned with segment entry time (4, 25).

RS (s, τ )

Congestion severity of s at τ (19).

Ĉ tt , Ĉ d , Ĉ s , Ĉ o

rk (vr , τ )

k-th candidate route for rerouted vehicle vr at τ .

Min–max normalized multi-cost terms in (29).

T (τ ) Šrv

Number of segments on candidate route rk .

T (τ ) for Priority-sorted copy of Srv sequential ARA.

S

Full set of road segments.

∥rk ∥ r̂(vr , τ )

Selected alternative route for vr at τ (29).

T , Tout

Aggregation period; forecast horizon length.

sp

(q)

q-th road segment of city zone zp .

(j)

j-th segment on candidate route rk (vr , τ ).

Bd(vr , s), ∆, s s ηs , zmax , zmin

Driver-behavior parameter and calibration factors (Sec. IV-D).

VA (·)

Driver-tailored segment speed; realized as V̂ in (17).

sk (vr , τ ) (i)

Sur (sc , τ )

Set of i-hop upstream segments of congested segment sc .

Crtt (rk )

Fused travel-time cost of candidate rk (28).

T (sc , τ ) Sur

Union of upstream layers 1, . . . , θur for sc (21).

Xτ

T Srv (sc , τ )

Network-wide history tensor of speed and occupancy over Tin steps.

Vehicles selected for rerouting w.r.t. sc (22).

fθ

Network-level spatio-temporal forecaster (LSTAN_GERPE / Rank).

Scr (vr , τ )

Set of Ncr candidate routes for vr .

LHuber

Backbone Huber speed-value loss.

V̄ (s, τ )

Mean speed on segment s at τ .

Lod ksp

V̂ (s, τ, vr )

Driver-tailored predicted average velocity of vr on s.

OD–k-shortest-path pairwise ranking loss (10).

T (P ; V )

V lim (s)

Speed limit on segment s.

Path travel time of candidate P under speeds V (8).

zp

p-th city zone.

λrank

Weight of Lod ksp in Rank fine-tuning.

Continued on next page

2026/8/19

14

Continued on next page

TABLE IV: Notations (editing reference; remove before submission) (Continued) Symbol

Description

Approaching route-hop budget

Fixed near-horizon budget (default 2) for route-based complement to θur .

wt , wd , ws , wo

Multi-cost weights for travel time, distance, similarity, occupancy.

CrT (·)

[obsolete] Old total-route cost; use Crtt / (29).

min Lmax rs , Lrs

[obsolete] Longest/shortest segment lengths; unused.

RL (s)

[obsolete] Normalized segment length; unused.

z RO (z(s), τ )

[obsolete] Zone occupancy ratio; unused.

Ψcr (s, τ )

[obsolete] Old K-SP edge weight; use (27).

2026/8/19

15

Related documents

• Unlocking air traffic flow prediction through microscopic aircraft-state modeling#665750
• Unlocking air traffic flow prediction through microscopic aircraft-state modeling#664250
• Toward a Decision-Assurance Layer for AI-Assisted Flight Planning in Air Traffic Management#1071332
• Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)#502040
• Probabilistic Multi-Agent Aircraft Landing Time Prediction#819272