11.4 AI Traffic Prediction and Optimization
11.4.1 Traffic-Flow Prediction Models
Short-term traffic-flow prediction is the key link that moves smart transportation from "perception" to "decision." Signal-timing optimization, dynamic route guidance, and congestion early warning all depend on judgments about vehicle flow over the next few minutes to half an hour. Traditional methods (historical averages or ARIMA models, for example) hold up under steady conditions, but as soon as they meet abrupt changes during morning and evening peaks or holiday pattern switches, their error rises sharply. Deep learning — the long short-term memory network (LSTM) in particular — has become the mainstream approach for short-term flow prediction thanks to its ability to capture long-range dependencies in time series. In recent years, Transformer-family models (such as Informer and PatchTST) and graph neural networks have achieved better accuracy in some scenarios; in practice, the choice is weighed against data scale and inference latency.
Data Sources and Feature Engineering
A prediction model depends on high-quality historical data. An urban road network has three main classes of traffic-flow observation sources, each with strengths and weaknesses:
- Inductive loop detectors: induction loops buried at intersections record vehicle counts, instantaneous speeds, and lane occupancy through electromagnetic induction. Their data is accurate, finely resolved in time (down to the second), and unaffected by weather — traditionally the "gold standard." The drawbacks: they cover only the cross-sections where loops are installed, and maintenance requires digging up the pavement.
- Video cameras and microwave radar: image recognition or microwave echo analysis extracts flow volume, vehicle-type classification, and average speed. Coverage is wider and several lanes can be monitored at once, but changes in lighting and occlusion by rain or snow reduce recognition rates, and the computational cost is higher.
- GPS floating cars: taxis, ride-hailing cars, or logistics vehicles periodically report position and speed, which aggregates into travel-time estimates per road segment. The advantage is network-wide coverage plus the ability to reflect actual driving routes; the weakness is insufficient sample size in low-flow periods (late night, for instance), producing obvious statistical bias.
In engineering practice these sources are mixed, with data-fusion algorithms (the Kalman filter, for example) filling in each source's blind spots. As a scenario example, suppose several weeks of minute-by-minute flow data are collected at a key intersection, with the earlier majority used for training and the later minority for testing.
The core of feature engineering is the sliding window: use the historical flow of the past T time steps as input to predict the flow of the next k time steps. Time features must be added as well. The concrete steps:
- Set the window length
T=96(the past 96 minutes) and the prediction horizonk=6(the next 6 minutes). - For each time point
t, extract the flow sequence over[t-T+1, t]as the sample input and the sequence over[t+1, t+k]as the label. Samples are spaced 1 minute apart. - Attach auxiliary features to each sample: time of day (the minute within the day, normalized to [0,1]), day of the week (encoded as a normalized scalar between 0 and 1), and a holiday flag (binary variable).
- Apply Z-score standardization across all samples to remove differences in scale.
The final input tensor then has shape (num_samples, 96, 3), where the 3 channels are the flow value, the time-of-day code (a normalized scalar), and the day-of-week code (a normalized scalar, with the holiday flag folded into the day-of-week channel).
LSTM Principles and Engineering Implementation
An LSTM manages what it remembers and forgets through three gated units — the forget gate, input gate, and output gate — avoiding the vanishing/exploding gradients of long-sequence training. In traffic-flow scenarios an LSTM can capture dependencies of several hours within the window — the climbing trend of the morning peak, the directional flip of tidal lanes — which linear models such as ARIMA struggle to express; but with this section's input window at T=96 minutes, a weekly-scale cycle cannot be retained automatically through the hidden state, so a lag feature of "flow in the same period one week ago" must be constructed explicitly and added to the input before the model can exploit weekly periodicity.
The following snippet implements training of the above model with the Keras (tf.keras) interface of TensorFlow 2.x, with the data handling assumed:
import numpy as np
from tensorflow.keras.models import Sequential
from tensorflow.keras.layers import LSTM, Dense, Dropout
from tensorflow.keras.optimizers import Adam
# Assume the data is already preprocessed: X_train (num_samples, 96, 3), y_train (num_samples, 6)
model = Sequential([
LSTM(units=64, input_shape=(96, 3), return_sequences=False),
Dropout(0.2),
Dense(6)
])
model.compile(optimizer=Adam(learning_rate=0.001),
loss='mse',
metrics=['mae'])
history = model.fit(X_train, y_train,
epochs=50,
batch_size=32,
validation_split=0.1)After training, evaluate the predictions on the test set:
from sklearn.metrics import mean_absolute_error, mean_squared_error
# X_test / y_test come from the earlier data split: the larger front portion of the
# continuously collected data is used for training, the smaller rear portion for testing
y_pred = model.predict(X_test)
mae = mean_absolute_error(y_test, y_pred)
rmse = np.sqrt(mean_squared_error(y_test, y_pred))
print(f"MAE: {mae:.2f} vehicles/min, RMSE: {rmse:.2f} vehicles/min")Evaluation Metrics and Engineering Trade-offs
- Mean absolute error (MAE): the average of absolute prediction errors, in the same units as raw flow (vehicles/minute). The most intuitive metric when explaining results to traffic engineers.
- Root mean square error (RMSE): penalizes larger errors more heavily, making it suitable for measuring how well the model captures abnormal flow spikes (accidents or temporary controls, for example). A low MAE paired with a conspicuously high RMSE means the model is unstable in a few extreme periods.
When tuning, engineers balance several factors: a larger window length T preserves longer historical dependencies but also adds model parameters and overfitting risk; the number of hidden units usually sits between 32 and 128, with 64 sufficient for most urban intersections; more than 2 layers is not recommended, or both training stability and inference speed degrade.
Flow patterns in an urban network drift slowly with seasons, large events, road construction, and similar factors, so the model needs periodic retraining (weekly, for example) and an edge-cloud collaboration architecture (see Section 11.3.3) to push the latest model down to edge nodes — "training in the cloud, inference at the edge." With this edge-cloud separation of training and inference, the prediction model can absorb pattern drift and stay effective over the long term, underpinning the closed loop of dynamic signal timing.
11.4.2 Traffic Signal Optimization and Control Algorithms
As a basis for discussion, fixed-time plans can stand in for the traditional control mode of many intersections — a phase table pre-arranged from historical flow for several periods of the day, leaving sudden congestion or abnormal flow nothing to do but wait for the next round of adjustment. Reinforcement learning redefines this scheduling problem as one of decision optimization: an intersection agent learns to allocate green time dynamically under different traffic-flow conditions through the closed loop of "observe — decide — feed back." This direction's move from academic research to engineering pilots depends on the gradual maturation of roadside sensing devices, edge computing, and traffic simulation environments.
Problem Modeling: The Intersection as an Agent
In the example, a single crossroads is abstracted as a reinforcement-learning agent. The environment comprises arriving vehicles, queues, and phase-time constraints; the agent observes the system state and chooses an action, the environment feeds back a reward signal, and the agent updates its policy accordingly. The whole process can be abstracted as a Markov decision process, and the core work is defining its three elements well: state, action, and reward.
State-space design — the state must capture the intersection's current congestion signature. The following is one typical design; specific dimensions can be adjusted to the intersection topology:
Table 11-10: Example state space for signal-control reinforcement learning
| State dimension | Description (example) |
|---|---|
| Queue length per lane on all four approaches | Vehicle count, from loop or camera detection |
| Remaining green time of the current phase | Continuous value, in seconds |
| Flow passed per phase in the last cycle | Reflects the inflow trend |
| Current period code | Morning peak, off-peak, evening peak, night |
Queue length and remaining phase time are the two most essential dimensions — the former directly reflects congestion severity, the latter determines the urgency of the action. The period code helps the model converge quickly under different flow patterns and, in off-peak periods, avoids extending greens too aggressively.
Action space — a discrete action set. Assume a standard crossroads has 4 main phases (east-west through, east-west left turn, north-south through, north-south left turn). A common practice defines an action as a tuple of (phase number, green-time extension). The extension uses a fixed step; assuming each phase can be extended by several steps, the action space is the Cartesian product of the two. A DQN (Deep Q-Network) converges stably on medium-sized discrete spaces like this. If the output is only a phase ID that forces a switch to the next phase, the ability to extend greens flexibly is lost, and off-peak periods easily produce green time wasted on empty approaches.
Reward-function design — the reward directly reflects the control objective: minimize total intersection delay. It is defined as follows:
$$ R_t = -\left( \sum_{i \in L} w_i \cdot q_i(t) + \alpha \cdot s(t) \right) $$
where:
- ( R_t ): the immediate reward at decision step ( t );
- ( L ): the set of all incoming lanes;
- ( q_i(t) ): the queue length of lane ( i );
- ( w_i ): the lane weight, with a larger coefficient for arterial roads;
- ( s(t) ): the total number of stops caused by red lights across lanes in the current cycle;
- ( \alpha ): a hyperparameter balancing average waiting time against stopping comfort.
When vehicles keep arriving but the green is too short, queues grow quickly and the reward falls, pushing the agent to extend the current phase or switch; when arrivals thin out, queues shrink and the agent learns to shorten greens, reducing waste on empty approaches. This is exactly the dynamic adjustment capability that fixed-time plans cannot deliver.
Note: the reward function above is a classic design for intersection RL problems; actual deployment requires calibrating the weights ( w_i ) and ( \alpha ) to the intersection's characteristics.
Training Approach and Typical Challenges
Training RL algorithms depends on a traffic simulator. Academia widely uses SUMO (Simulation of Urban Mobility) as the environment, connecting a DQN through the TraCI interface for large-scale interactive training. The engineering cost lies mainly in building a realistic road-network topology and configuring sensible traffic-flow parameters, not in the algorithm code itself.
Engineering applications face two prominent difficulties.
Incomplete state observation. A real intersection can only see queue lengths at its approaches through magnetic induction loops or cameras; it cannot obtain the globally exact values a simulator provides. One effective remedy is to include the action history of the past few steps in the state vector, partially restoring unobserved information. Switching to a partially observable MDP variant is another option, but training complexity rises markedly.
Training stability. In the early stage of training, the rewards produced by the agent's random actions are generally low and Q-value variance is enormous. Common remedies include: setting a "warm-up period" in which fixed-time control dominates while the RL explores within a narrow range; or using a DQN variant with prioritized experience replay that takes the absolute TD error as sampling priority, accelerating learning from critical samples.
After sufficient training, the agent typically outperforms fixed-time plans significantly across different traffic volumes. The magnitude of the improvement varies with intersection topology and flow. It must be stressed that in engineering deployment, the reinforcement-learning output does not directly and unconditionally set green durations: constraints such as minimum green time, yellow-change intervals, and emergency-vehicle priority are guaranteed by deterministic rules, and the model's output takes effect only within those safety boundaries.
From a Single Intersection to Networked Control
Single-intersection RL control is only the starting point. Real urban traffic requires area-level coordination — adjacent intersections must share phase offsets and queue lengths. Multi-agent reinforcement learning already has a large body of academic research but few engineering deployments, with the main bottlenecks being signal-controller vendors' proprietary protocols and latency-sensitive communication constraints. An engineering-workable compromise is to introduce a regularization term for the average queue length of neighboring intersections into the single-intersection reward, so that each agent's optimization objective carries a share of global information and thus trends toward area coordination to a certain extent.
11.4.3 Energy Optimization and Smart Lighting
Streetlight optimization is a typical entry point for energy saving in a smart city. Traditional strategies mostly switch all lamps on and off by schedule — in the late night, when street traffic is very low, an entire street still runs at full power. The goal of AI dimming is to adjust each lamp's brightness dynamically from real-time pedestrian and vehicle flow without lowering public safety. Everything below in this section is an illustrative scenario: the data and parameters serve to illustrate principles and methodology and do not represent actual project results.
Deep Q-Network Dimming Model
When streetlight dimming is placed in a reinforcement-learning framework, each lamp is abstracted as an independent agent. The state, action, and reward designs below are all illustrative.
State space. Centered on a single smart streetlight pole, the state vector consists of four classes of observation: ambient background illuminance (from a photoresistor), radar-detected vehicle flow, pedestrian counts from an infrared sensor, and the current brightness ratios of neighboring lamps. Neighbor brightness is included to prevent large brightness differences between adjacent lamps from creating a "zebra-stripe" effect on the road surface. All observations are normalized to [0,1] before entering the network.
Action space. A discrete action set — in the example it is designed as four levels: off, dim glow, energy-saving, and full brightness. The levels map one-to-one to PWM duty cycles, and the exact percentages must be calibrated to the luminaire model and on-site acceptance criteria. Choosing discrete levels over continuous dimming is an engineering trade-off driven by deploying the inference engine on a resource-constrained microcontroller — too fine a granularity would inflate the exploration space, and an embedded processor's compute and memory could hardly support it.
The reward function drives two objectives at once — low power consumption and public safety. The formula is R = -w₁·Power - w₂·Defect_penalty, where w₁ and w₂ are weight coefficients to be tuned. Defect_penalty fires when road-surface illuminance falls below the safety threshold while pedestrians and vehicles are detected at the same time, and its weight is usually significantly larger than the energy-saving weight.
Training takes place in a digital twin environment. Each lamp learns its policy independently, but because the state includes neighboring lamps' current brightness, the agents can achieve cluster coordination automatically — the lamps along a street can light up in sequence and fade out gradually as a pedestrian moves along. This idea of "centralized training, distributed execution" follows the same line as the signal reinforcement-learning design in Section 11.4.2.
Dimming-Policy Decision Loop
The following is pseudocode for a single streetlight agent's decision loop; the parameters depend on hardware selection and the deployment scenario.
# Dimming-policy decision loop (decision interval is a tunable parameter; illustrative value 30s)
INTERVAL_S = 30
BRIGHTNESS = [0, 30, 60, 100] # Four brightness levels in percent, illustrative values
while True:
sleep(INTERVAL_S)
# 1. Collect sensor observations
state = normalize([
read_ambient_light(), # Ambient illuminance
read_radar_flow(), # Vehicle flow
read_pir_count(), # Pedestrian count
mean_neighbor_bright() # Normalized brightness of neighboring lamps
])
# 2. DQN selects an action (epsilon-greedy exploration)
if random() < EPSILON:
action = random_choice(4) # Random exploration
else:
q_values = dqn.predict(state)
action = argmax(q_values) # Greedy action
# 3. Set the PWM duty cycle
pwm_duty = BRIGHTNESS[action] / 100.0
set_pwm(pwm_duty)
# 4. Experience cache (computed asynchronously by the edge node)
# push_to_replay_buffer(state, action, next_state)The decision interval trades off controller lifetime against the speed of traffic change; in practice it is tuned within a range of 10 to 60 seconds.
Evaluating Energy Savings
In this example, evaluation typically focuses on three metrics (the metrics illustrate the control trade-offs): energy saved, illuminance compliance, and recovery response after a burst of traffic. The following compares power curves for a secondary road.
Energy saving alone is not the end point. Streetlights are among the densest pieces of infrastructure in urban public space, bringing their own power supply, network, and pole structure. Once the lighting layer is well optimized with AI, the cameras, environmental sensors, and 5G micro base stations integrated on the same pole can all share this decision framework. Traffic-prediction conclusions can drive lighting strategy in reverse: if the AI predicts congestion on a road segment half an hour ahead, lamp brightness can be raised in advance. This gradually blurring coordinated scheduling between lighting and traffic is precisely where the urban agent lands as it moves from single-point optimization toward system-level intelligence.