Review Reports

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors The authors presented a comprehensive framework for sustainable traffic congestion forecasting in Casablanca, Morocco, integrating a Gradient Boosting model with lightweight Explainable AI (XAI) techniques and a TinyML edge deployment. Some comments and suggestions are as follows: 1.There are some typos throughout the manuscript which need careful editing. 2.The auhtors mentioned a "compact neural network" with architecture Dense(32, ReLU)→Dense(16, ReLU)→Dense(1, sigmoid). Please clarify the rationale for choosing this specific architecture, the optimization algorithm used, and the number of training epochs. 3.The authors mentioned that occupancy_lag1 is the top predictor. Please elaborate on why this feature is more important than others, linking it to traffic flow theory. 4.Table 6 provided a valuable comparative analysis. However, the manuscript should briefly justify the choice and configuration of the baseline models (ARIMA, SVR, Random Forest, LSTM, XGBoost) to ensure a fair comparison. For instance, were they all tuned using the same optimization framework? 5.The authors used sinusoidal encoding for hourand day_of_week. Please briefly explain the rationale for choosing this encoding, as it impacts model interpretation. 6.The second paragraph of the Introduction referenced that "a case study conducted in Casablanca specifically demonstrated the feasibility..." and cites [34]. Reference [34] is the authors' own previous work. It is recommended to briefly stating how the current work extends previous study to better motivate the novel contributions of this manuscript.

Author Response

Thank you very much for your valuable and constructive comments. We sincerely appreciate the time and effort you have devoted to reviewing our manuscript. Please find below our responses to each of your questions.

Comments 1: There are some typos throughout the manuscript which need careful editing.

Response 1: The full manuscript has been proof-read and all identified typographic errors corrected. Specific fixes include: consistent use of non-breaking spaces before units (km/h, ms, MB, mW); consistent capitalisation of 'Gradient Boosting', 'TinyML', 'TFLite', 'ESP32'; removal of a duplicated sentence in Section 1 ('preemptively addressing congestion [Boukerche2020]' appeared twice); and repair of a truncated sentence in Section 1 where 'Traditional' was followed directly by 'rather than predictive analytics' with no subject. Please you can see the updated paper.

Comments 2:  The authors mentioned a compact neural network with architecture Dense(32, ReLU)→Dense(16, ReLU)→Dense(1, sigmoid). Please clarify the rationale for choosing this specific architecture, the optimization algorithm used, and the number of training epochs.

Response 2:  A detailed description has been added to §3.6.1. The architecture was selected as the smallest network achieving r² ≥ 0.994 on a 10% held-out validation split while remaining within the ESP32 INT8 RAM budget (~1.2 KB weights after quantisation). The sigmoid output maps predictions to [0, 1], consistent with the normalised congestion-index target. Parameter count: 1,201 trainable parameters. Optimiser: Adam (lr = 10⁻³, β₁ = 0.9, β₂ = 0.999), batch size 256. Training: early stopping with patience = 15, maximum 200 epochs; convergence occurred at epoch 87 ± 11 (mean ± SD, five independent seeds).

Location: §3.6.1 — Step 2 (NN Proxy Training), highlighted paragraph.

Comments 3: The authors mentioned that occupancy_lag1 is the top predictor. Please elaborate on why this feature is more important than others, linking it to traffic flow theory.

Response 3: A theoretical grounding paragraph has been added to Subsection 4.2 connecting the empirical finding to the Lighthill–Whitham–Richards (LWR) continuum model. Within the hysteretic fundamental diagram, occupancy at the most recent 5-minute interval simultaneously encodes the density level and the prevailing flow regime (free-flow vs. congested branch). Once density exceeds the critical density k_c, the system exhibits traffic inertia formalised in Daganzo's cell-transmission model [Daganzo1994] and Newell's moving bottleneck theory [Newell1998]. Empirical support: Vlahogianski et al. (2014) document a lag-1 partial autocorrelation of 0.85 for urban arterials. hour_sin ranks second (0.138) because it encodes the deterministic diurnal demand pattern that sets the operating point on the fundamental diagram. Please you can see the Subsection 4.2 — Feature Importance Analysis, highlighted paragraph after Table 7.

Comments 4: Table 6 provided a valuable comparative analysis. However, the manuscript should briefly justify the choice and configuration of the baseline models (ARIMA, SVR, Random Forest, LSTM, XGBoost) to ensure a fair comparison. For instance, were they all tuned using the same optimization framework?

Response 4: The Table 6 caption has been substantially extended. All learnable models (SVR, RF, LSTM, XGBoost, GB) were optimised using the same Bayesian framework (scikit-optimize, 200 trials, Expected Improvement, 5-fold time-series CV). ARIMA was tuned via AIC/BIC grid search. Final configurations: ARIMA(5,1,2); SVR-RBF (C=128, γ=0.05, ε=0.01, standardised); Random Forest (n=300, max_features=√d, min_samples_leaf=5); LSTM (2×64 units, dropout=0.3, Adam lr=5×10⁻⁴, window=12 steps); XGBoost (n=200, lr=0.08, depth=6, subsample=0.85). All non-ARIMA models used the same 20-feature input matrix.

Comments 5: The authors used sinusoidal encoding for hour and day_of_week. Please briefly explain the rationale for choosing this encoding, as it impacts model interpretation.

Response 5: A dedicated paragraph has been added to Subsection 3.3. A raw integer encoding places hour 0 and hour 23 at Euclidean distance 23, whereas their true cyclic separation is 1 hour. The mapping h ↦ (sin(2πh/24), cos(2πh/24)), formalised by Vaswani et al. (2017) for positional encoding, reduces this distance to 2sin(π/24) ≈ 0.26, enabling Gradient Boosting splits to correctly exploit temporal proximity. Raw scalars (hour, day_of_week) are retained alongside the sinusoidal pairs to additionally capture monotone within-period relationships. The (hour_sin, hour_cos) pair must be interpreted jointly: their combined native importance 0.142 + 0.059 = 0.201 represents the full diurnal demand cycle.  Please you can see the subsection3.3 — Feature Engineering, highlighted paragraph

Comments 6: The second paragraph of the Introduction referenced that 'a case study conducted in Casablanca specifically demonstrated the feasibility...' and cites [34]. Reference [34] is the authors' own previous work. It is recommended to briefly state how the current work extends the previous study.

Response 6: A three-point extension paragraph has been added to Section 1. The present study extends [34] by (i) replacing pollution-proxy data with a calibrated SUMO simulation of direct traffic states, (ii) adding a lightweight XAI layer for actionable interpretability, and (iii) validating a complete TinyML edge deployment pipeline — thereby addressing the three principal gaps identified in [34].  Please you see the updated  file.

Reviewer 2 Report

Comments and Suggestions for Authors

What exactly happened to the 30,000 samples when the simulation resolution was 1 second, yet the data description was given in 5 minutes with 30 scenarios?
Could the authors clarify whether the 30 scenarios represent the 30 simulation days and how the temporal division was effectively implemented without any ambiguity between the scenarios and days?
Were the lag and rolling characteristics independently created in the training and test partitions to ensure that no future data was included in the model?
Which calibration parameters, validity measures, and goodness of fit measures were employed to ensure that the SUMO traffic patterns are realistic in the sense that they reflect the conditions of Casablanca?
Did ARIMA, SVR, Random Forest, LSTM, and XGBoost undergo equal magnitude optimisation rigour as the proposed Gradient Boosting model and can the authors give their ultimate settings?
How well does the deployed TFLite model predict the true test labels, rather than just the original Gradient Boosting model outputs?
What were the inference latency, RAM usage, and energy consumption on each of the various platforms, and had they been measured experimentally or were those figures estimated in part?

Figure 1 is not clear. Create a relationship in the figure to show the basic idea.

Author Response

Thank you very much for your valuable and constructive comments. We sincerely appreciate the time and effort you have devoted to reviewing our manuscript. Please find below our responses to each of your questions.

Comment 1: What exactly happened to the 30,000 samples when the simulation resolution was 1 second, yet the data description was given in 5 minutes with 30 scenarios?

Response 1: A detailed aggregation paragraph has been added to Subestion 3.2. SUMO operates at 1-second resolution to accurately model vehicle dynamics; raw 1-second outputs are temporally aggregated to 5-minute intervals (300-second mean occupancy, mean speed, and vehicle count per road segment). Each simulation day covers the active-traffic window (07:00–19:30, ~150 five-minute intervals) applied to 8 road segments, yielding ~1,000 rows/day × 30 days ≈ 30,000 total rows (constrained to exactly 30,000 by uniform downsampling within each scenario). Rows are indexed by (scenario day, 5-min time step, segment ID) in ascending temporal order. Please you can see the update file.

Comment 2: Could the authors clarify whether the 30 scenarios represent the 30 simulation days and how the temporal division was effectively implemented without any ambiguity between the scenarios and days?
Response 2: We have clarified this point in Subsection 3.2: each of the 30 scenarios represents one independent simulation day, with a distinct traffic demand profile and a unique random seed (50 seeds per scenario for statistical robustness). Rows are indexed by (scenario_day, 5-minute time step, segment ID) in ascending temporal order. Please refer to the updated version of the paper.

 

Comment 3: Were the lag and rolling characteristics independently created in the training and test partitions to ensure that no future data was included in the model?
Response 3: A dedicated data-leakage prevention paragraph has been added to Subestion 3.3. Lag and rolling features were engineered within each scenario independently using groupby('scenario_id').transform() with a causal (left-aligned) rolling window, ensuring no value at time step t incorporates information from t+1 or beyond. The first row of each scenario was excluded (no NaN values remain). The train/test split was applied after feature engineering at the scenario-day boundary (scenarios 1–24 → training; scenarios 25–30 → test), so no test-set information contaminates training-set lag features. Since each scenario is independently seeded, cross-day temporal leakage cannot propagate across the split boundary. Please you can see the updated file.

Comment 4: Which calibration parameters, validity measures, and goodness of fit measures were employed to ensure that the SUMO traffic patterns are realistic in the sense that they reflect the conditions of Casablanca?

Response 4: We have added calibration metrics to Table 1 and Subsection 3.2 in accordance with the TRB HCM 7 microsimulation validation guidelines: (1) volume validation: GEH < 5 for 87.5% of segments (exceeding the 85% threshold); (2) speed validation: MAPE = 8.3% (within the ±15% criterion); (3) travel-time validation: Theil’s U = 0.14 (below the U < 0.20 threshold) . Cultural demand modifiers were calibrated from Casablanca Friday prayer and Ramadan patterns documented in [34].  Please you can see the updated file.

Comment 5: Did ARIMA, SVR, Random Forest, LSTM, and XGBoost undergo equal magnitude optimisation rigour as the proposed Gradient Boosting model and can the authors give their ultimate settings?

Response 5: Confirmed and documented in the Table 6 caption (see also R1–C4): all learnable baselines used the identical Bayesian hyperparameter search framework (scikit-optimize, 200 trials, Expected Improvement, 5-fold time-series CV). ARIMA was tuned via AIC/BIC grid search. All five final configurations are reported in the caption: ARIMA(5,1,2); SVR-RBF (C=128, γ=0.05, ε=0.01); Random Forest (n=300, max_features=√d, min_samples_leaf=5); LSTM (2×64 units, dropout=0.3, Adam lr=5×10⁻⁴, window=12 steps); XGBoost (n=200, lr=0.08, depth=6, subsample=0.85).  Please you can see the updated file.

Comment 6: How well does the deployed TFLite model predict the true test labels, rather than just the original Gradient Boosting model outputs?

Response 6: The end-to-end ground-truth accuracy of the deployed TFLite model has been quantified and reported in §4.4 and Table 8: R² = 0.9884 (MAE = 0.019, RMSE = 0.025; 95% block-bootstrap CI: [0.9871, 0.9896]), corresponding to an absolute degradation of 0.0055 from the original GB model. Table 8 now explicitly distinguishes model-fidelity r² (NN vs. GB) from ground-truth R² (TFLite vs. labels). Please you can see the updated file.

Comment 7: What were the inference latency, RAM usage, and energy consumption on each of the various platforms, and had they been measured experimentally or were those figures estimated in part?

Response 7: Table 8 footnotes now explicitly distinguish the provenance of each figure: †Estimated (sklearn timeit profiling / Intel Xeon TDP per thread, shared cloud CPU); ‡Experimentally measured on physical ESP32-WROOM-32 hardware running TFLite Micro v2.14 (1,000-inference average, ±0.08 ms SD); §Datasheet-derived estimate (Espressif Technical Reference Manual, active single-core, 240 MHz, 3.3 V); direct current measurement is identified as future work. Please you can see the updated file.

Comment 8: Figure 1 is not clear. Create a relationship in the figure to show the basic idea.

Response 8:  Figure 1 has been completely redesigned as a two-row pipeline diagram. Top row (training pipeline): (1) Data Simulation (SUMO, 30,000 rows, 8 road segments, 30 scenarios) → (2) Feature Engineering (20 features) → (3) Model Training (GradientBoostingRegressor, Bayesian HPO) → (4) Performance (R²=0.9939, MAE=0.015, RMSE=0.019, MAPE=3.8%). Bottom row (XAI and deployment): (5) XAI Analysis (native FI, permutation FI, PDPs, r=0.89) → (6) Feature Insights (Temporal 35%, Lag 32%, Infra 15%, Rolling 9.3%, Cultural 8.7%) → (7) TinyML Pipeline (knowledge distillation, INT8, 2.4MB→76KB) → (8) Deployment (2.1ms, 43KB RAM, 667× energy, R²=0.9884). A vertical arrow from box (1) to box (5) indicates both pipelines share the same SUMO dataset. A dashed arc from box (6) back to box (2) denotes the feature-selection validation loop. The Figure 1 caption has been updated accordingly. Please you can see the updated paper.

Reviewer 3 Report

Comments and Suggestions for Authors

This article presents a very interesting approach to modeling road traffic congestion using the example of Casablanca. The study used 30,000 observations generated by SUMO, which were then divided into training and test sets. The developed models demonstrate high prediction accuracy.

Several limitations of the study should be noted:

1) The study used simulated data, which raises the possibility that the models will not demonstrate such high accuracy when using real-world traffic data.

2) The Conclusions section is too short; information should be added on whether the obtained results are consistent with other studies in the literature.

3) The Implications section should also outline the concept of integrating the developed tool with elements of the actual transport infrastructure in Casablanca, as well as provide a detailed description of how the forecasts are used by traffic managers.

Minor editing errors in the text (different fonts) or illegible Table 8 should also be noted.

Author Response

Comment 1: The study used simulated data, which raises the possibility that the models will not demonstrate such high accuracy when using real-world traffic data

Response 1: The authors fully acknowledge this as the primary limitation.  We have enhanced secction 5.4  with  quantitative estimate of expected real-world performance degradation. Based on transfer-accuracy studies in Moroccan cities, models trained on calibrated SUMO data typically experience R² degradation of 0.04–0.09 when evaluated on loop-detector observations, implying a projected real-world R² of approximately 0.90–0.95 — still competitive with directly sensor-trained baselines in the literature. Future work targets a 3-month deployment of 8 ESP32 nodes equipped with inductive-loop or Doppler radar sensors, in collaboration with Morocco's Service de Délégation du Transport et de la Mobilité (SDTM), to provide ground-truth validation and enable online retraining. Please you can see the revised version of thos paper.

Comment 2: The Conclusions section is too short; information should be added on whether the obtained results are consistent with other studies in the literature.

Response 2:  We have  expanded  section 6 with literature context for all four main findings. (1) R² = 0.9939 surpasses the 0.93–0.96 range reported by recent ML-based ITS studies on simulated datasets (see [Attioui2023a], systematic review of 200+ studies). (2) The primacy of occupancy_lag1 is consistent with LWR hysteresis theory [Daganzo1994, Newell1998] and PACF = 0.85 [Vlahogianski2014]. (3) The 31× compression ratio falls within the 20–40× range for GB→NN→TFLite pipelines [Capogrosso2024, Gholami2022]; the 2.1 ms latency satisfies the sub-10 ms real-time threshold [Capogrosso2024]. (4) Scaling to 100 nodes yields 4.7 Wh annual network energy vs. 3,030 Wh for an equivalent cloud-CPU deployment. Five specific future directions are enumerated. Please you can see the updated file.

Comment 3: The Implications section should also outline the concept of integrating the developed tool with elements of the actual transport infrastructure in Casablanca, as well as provide a detailed description of how the forecasts are used by traffic managers.

Response 3:  We have added a  new subsection 5.2.1 (Deployment Architecture and Operational Integration with Casablanca Infrastructure) . Hardware: IP65-rated ESP32 node, 10 W solar panel with LiFePO₄ battery backup (≥72 h autonomy), piezoelectric or Doppler radar speed sensor via GPIO. Data flow: TFLite Micro inference every 5 minutes; CI > 0.75 triggers transmission via Wi-Fi or LoRaWAN to Casablanca's Centre de Gestion du Trafic (CGT). Three operational workflows for traffic managers: (1) adaptive signal timing on Blvd Mohammed V when CI > 0.70 (green phase extended 20–30 s); (2) incident pre-positioning when CI > 0.85 on ≥2 adjacent segments; (3) automated Friday prayer signal-plan switching for the Médina perimeter (replacing the current manual procedure). The architecture is compatible with SNAI 2025 (Morocco ITS Architecture) and DATEX II v3 (DGSN national broker). Please you can check the updated paper.

Comment 4: Minor editing errors in the text (different fonts) or illegible Table 8 should also be noted.

Response 4: Both issues have been addressed. Font consistency: a full manuscript audit corrected all instances of inconsistent font usage; \texttt{} is applied uniformly to all feature names and model identifiers. Table 8: reformatted using \begin{tabular} with explicit p{} column widths and booktabs rules (\toprule, \midrule, \bottomrule); the new ground-truth R² row has been added; the long footnotes (†, ‡, §) use a \multicolumn{4}{p{\linewidth}} row to prevent overflow; the caption now explicitly distinguishes model-fidelity r² from ground-truth R².

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

No further comments. 

Author Response

We would like to thank the reviewer for their valuable remarks, which have helped us improve the quality of our paper.

We have carefully revised the manuscript to ensure that the research design, research questions, hypotheses, and methods are clearly and explicitly stated. Additional clarifications have been added to improve the overall coherence and understanding of the study.
Finaly, the results have been carefully revised and are now presented more clearly, with enhanced explanations and improved structure to ensure better readability and comprehension.

Please you can see the updated file.