A Hybrid IoV-MEC-AI Framework for Road Safety: An Ex Ante Feasibility Assessment on the General Rumiñahui Highway

Abstract

Road traffic crashes remain a major public safety concern in Ecuador, particularly on the General Rumiñahui Highway, which is a high-demand mountainous corridor characterized by a complex road geometry, variable traffic conditions, changing environmental conditions, and limited proactive early warning capabilities. This study proposes a hybrid Internet of Vehicles (IoV)–multi-access edge computing (MEC)–artificial intelligence (AI) framework and assesses its technical and contextual feasibility through an ex ante analysis of the target corridor. The three-layer architecture integrates roadside, vehicular, and environmental sensing for data acquisition; MEC-enabled local processing, YOLOv8-based visual perception, and V2V, V2I, and V2P communications at the edge; and cloud-based spatiotemporal crash risk estimation using a CNN-LSTM model. ISO 37106:2021 and ISO 37122:2019 are adopted as design references for interoperability, smart city integration, and mobility-related monitoring. The feasibility assessment combines evidence from functionally comparable IoV, computer vision, predictive modeling, and MEC/V2X studies with an analysis of candidate Ecuadorian institutional data sources and corridor-specific deployment constraints. Literature-derived performance metrics are used only as feasibility evidence and are not interpreted as empirical measurements or the expected performance of the proposed framework. The results indicate that the architecture is technically plausible and contextually feasible under explicit conditions, providing a structured basis for Phase II digital twin evaluation followed by an instrumented field pilot under real operating conditions.

1. Introduction

Road traffic crashes remain a major public safety and mobility challenge, causing more than one million deaths annually worldwide and disproportionately affecting vulnerable road users [1]. In Ecuador, 8718 crashes and 1022 deaths were reported between January and May 2026 [2]. These figures reinforce the need to complement conventional enforcement and emergency response measures with proactive mechanisms capable of identifying hazardous conditions and supporting timely preventive action, consistent with Sustainable Development Goal v3.6 [3].

This need is particularly relevant on the General Rumiñahui Highway, a high-demand corridor connecting Quito with the eastern valleys. Its steep gradients, sharp curves, high-speed sections, variable traffic conditions, and changing weather and visibility create a challenging operating environment for preventive road safety systems. Technologies such as the Internet of Vehicles (IoV), multi-access edge computing (MEC), computer vision, and spatiotemporal artificial intelligence (AI) offer complementary capabilities for sensing, information exchange, local processing, and risk analysis [4,5,6,7,8,9,10,11,12].

However, their effectiveness is strongly context-dependent. Computer vision performance varies with illumination, occlusion, weather, camera placement, and hardware configuration [8,13], while V2X communication is affected by mobility, congestion, interference, coverage, handover, and LOS/NLOS propagation. IoV deployments also introduce interoperability, security, privacy, scalability, and data trust requirements [5,14]. Consequently, results obtained with different datasets, hardware platforms, communication technologies, and traffic environments cannot be directly transferred to the General Rumiñahui Highway.

Although the individual enabling technologies are well established, the reviewed literature does not provide an integrated architecture specifically adapted to the geometric, communication, institutional, and data integration constraints of the target corridor. The research gap is therefore architectural and contextual rather than algorithmic: the unresolved problem is how established IoV, MEC, V2X, visual perception, and spatiotemporal modeling components can be integrated into a coherent road safety framework suitable for this operating environment.

To address this gap, this study proposes a three-layer hybrid IoV-MEC-AI framework. Layer 1 comprises roadside, vehicular, and environmental sensing; Layer 2 integrates MEC-enabled preprocessing, YOLOv8-based perception, multimodal feature fusion, and V2V, V2I, and V2P communications; and Layer 3 performs cloud-based spatiotemporal crash risk estimation using a CNN-LSTM model. ISO 37106:2021 and ISO 37122:2019 are adopted as design references for interoperability, smart city operational integration, and mobility-related monitoring [15,16].

The study conducts an ex ante technical and contextual feasibility assessment. Literature-derived performance values are used only as evidence of technological plausibility and as references for candidate requirements, rather than as indicators of the measured or expected performance of the proposed framework. The assessment also considers candidate Ecuadorian institutional data sources, communication and interoperability constraints, and the requirements that must be evaluated during subsequent controlled experimentation.

Accordingly, the study addresses the following research question:

To what extent is the proposed hybrid IoV-MEC-AI framework technically and contextually feasible for supporting future real-time crash risk estimation and preventive alerting on the General Rumiñahui Highway?

The main contributions of this study are as follows:

• A context-specific three-layer IoV-MEC-AI architecture integrating multimodal sensing, YOLOv8-based visual perception, MEC/V2X processing, and CNN-LSTM-based crash risk estimation;
• An ex ante feasibility assessment that distinguishes literature-based technological evidence from corridor-specific empirical performance and identifies the conditions required for controlled validation;
• The identification of candidate Ecuadorian institutional data sources and associated data integration, communication, and interoperability requirements aligned with ISO 37106:2021 and ISO 37122:2019;
• A staged validation roadmap progressing from the present architectural assessment to digital twin evaluation and, subsequently, an instrumented field study under real operating conditions.

2. Literature Review

Road safety systems for high-demand transportation corridors must account for traffic dynamics, roadway and environmental conditions, sensing quality, communication reliability, and the processing of heterogeneous information within operationally relevant time windows. Existing research addresses these requirements through Internet of Vehicles (IoV), Vehicle-to-Everything (V2X) communications, computer vision, machine and deep learning, sensor fusion, and edge–cloud computing [4,17,18]. However, these technologies have been evaluated under heterogeneous datasets, environments, hardware platforms, and experimental protocols. The literature is therefore used in this study to establish a technological precedent, design requirements, and known limitations rather than to infer corridor-specific performance.

No empirical study was identified in the reviewed literature that integrates IoV, MEC, computer vision, V2X communications, and spatiotemporal crash risk modeling specifically for the General Rumiñahui Highway or the Quito–Valles corridor. The review consequently focuses on the technological evidence required to determine whether such an integrated architecture is sufficiently justified for subsequent controlled evaluation.

2.1. Internet of Vehicles and V2X Communications

The Internet of Vehicles extends Internet of Things concepts to dynamic transportation environments in which vehicles, infrastructure, road users, sensors, and digital services exchange information. Communication modes such as Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Pedestrian (V2P), and Vehicle-to-Everything (V2X) support cooperative perception, traffic management, collision avoidance, and safety message dissemination [4,5,19,20]. Figure 1 summarizes these communication relationships and their principal functional roles.

Figure 1. Principal Vehicle-to-Everything (V2X) communication modes and their functional roles in connected road safety environments. V2V supports direct vehicle communication, V2I connects vehicles with roadside and edge infrastructure, V2P enables interaction with pedestrians and vulnerable road users, and V2N provides access to network and cloud services.

Reliable V2X operation remains challenging because vehicular networks are affected by mobility, rapidly changing topologies, radio interference, channel congestion, resource contention, coverage, and heterogeneous propagation conditions [21,22]. Routing studies address these conditions through mobility- and link quality-aware geographic forwarding, grouped-RSU hierarchical routing, and RIS-assisted multi-hop communication. DPCI-GPSR incorporates directional propagation capacity and link quality to improve packet delivery under varying mobility and vehicle density levels [23], while LSRGR combines reliable route selection, location-aware forwarding, and recovery mechanisms for highly dynamic VANETs [24]. Grouped-RSU hierarchical reinforcement learning has also been proposed to support distributed routing decisions under dynamic urban conditions [25]. At the propagation level, IRS- and STAR-RIS-assisted schemes provide alternative V2V paths when direct LoS communication is obstructed and support multi-hop relay selection and end-to-end delay reduction [26,27]. These mechanisms represent candidate functions of the underlying V2X infrastructure rather than routing contributions of the proposed architecture.

Communication modes must also be distinguished from radio-access technologies: V2V, V2I, and V2P define the communicating entities, whereas DSRC/IEEE 802.11p [28], LTE-V2X/C-V2X, and NR-V2X represent alternative communication technologies. Accordingly, safety-oriented communication should be evaluated through measurable indicators such as end-to-end latency, message delivery reliability, service availability, the packet delivery ratio, and the communication load.

Security and trust are equally relevant because V2X systems exchange safety-sensitive information. Authentication, integrity, privacy, trust management, and intrusion detection must operate under intermittent connectivity and high mobility [5,19,29,30]. These communication and security functions are treated as enabling infrastructure requirements rather than as new routing or radio-resource contributions.

2.2. Environmental Perception, Sensor Fusion, and Computer Vision

Reliable road environment perception benefits from heterogeneous sensing because no individual modality performs consistently under all traffic, illumination, weather, and visibility conditions. Cameras, radar, LiDAR, GPS, OBD-II, MEMS, and environmental sensors can provide complementary observations of traffic flows, vehicle dynamics, roadway states, and environmental conditions [4,31].

Computer vision is particularly relevant for non-intrusive traffic monitoring. YOLO-based architectures have been applied to vehicle detection, classification, counting, congestion analysis, and traffic state extraction, as reported by Yu [7], Shreya and Kumar [32], and Castillo et al. [33]. Yu [7], for example, combines an optimized YOLOv8 architecture with virtual induction loops and temporal processing to address small vehicles, occlusions, and frame-to-frame instability while producing traffic flow and density information.

Nevertheless, vision performance remains dependent on illumination, occlusion, the object scale, the camera perspective, motion blur, weather, the traffic density, sensor placement, and computational hardware [7,9]. YOLOv8 is therefore supported as a suitable perception component, but its robustness must ultimately be established under corridor-specific sensing conditions. Driver state monitoring represents a possible extension, whereas the present architecture prioritizes roadway, vehicular, traffic, and environmental observations [31,34,35].

2.3. Spatiotemporal Road Risk Modeling and Heterogeneous Data

Road safety modeling has employed statistical methods and conventional machine learning algorithms such as decision trees, support vector machines, K-nearest neighbors, random forest, and regression models for collision risk and injury severity analysis [36,37,38]. Relevant explanatory variables include speed, roadway characteristics, weather, lighting, temporal conditions, and infrastructure factors.

Because road risk evolves across both space and time, recent approaches incorporate recurrent, convolutional, graph-based, and attention mechanisms. LSTM-based and hybrid CNN–LSTM architectures have also been investigated for accident frequency forecasting, real-time crash risk estimation, and accident impact prediction, as reported by Siswanto et al. [39], Li et al. [40], Uğuz and Büyükgökoglan [41], and Sajadi et al. [42]. Wang et al. [6] proposed a GNN-LSTM architecture that combines geographic relationships with temporal modeling and explicitly addresses class imbalance through ADASYN and focal loss.

These studies provide methodological support for spatiotemporal risk modeling but also show that the performance depends on spatial representation, temporal windows, the class distribution, feature selection, the geographic context, and the validation strategy. For this reason, CNN-LSTM is considered in the proposed framework as a candidate architecture for integrating spatial/local and temporal information, rather than as a model with established performance on the target corridor.

Predictive modeling also depends on the integration of heterogeneous fixed and mobile data sources. Traffic systems may combine cameras, GPS, OBD information, environmental measurements, roadway characteristics, emergency events, and historical crash records [31,43]. Their integration requires consistent spatial references, temporal synchronization, semantic harmonization, and quality control. Furthermore, temporal or spatiotemporal train–validation–test partitions are preferable to random sample splitting when neighboring observations could otherwise introduce information leakage [6,9].

2.4. MEC and Hybrid Edge–Cloud Architectures

The placement of computational tasks is a critical design decision for latency-sensitive transportation systems. Cloud infrastructures support model training, historical storage, and system-wide analytics, but exclusive dependence on remote processing can increase communication delays. Multi-access edge computing (MEC) addresses this limitation by placing computational resources closer to vehicles and roadside infrastructure.

Existing evidence supports hybrid edge–cloud architectures in which edge resources perform filtering, inference, and immediate decision logic, while cloud resources support computationally intensive training, historical analysis, and model management [10,12,44]. Embedded processing studies further show that inference performance depends on hardware and model complexity; Chaurasia et al. [45], for example, report different inference latencies across the Jetson Nano and Raspberry Pi platforms.

Accordingly, communication latency must be evaluated end to end, including sensing, preprocessing, radio transmission, queueing, edge inference, decision generation, and alert dissemination. MEC can shorten several of these components but does not eliminate them. The reported latency values therefore provide evidence of technical plausibility and guidance for defining candidate requirements, while the actual performance remains dependent on the selected hardware, network configuration, traffic load, and communication conditions.

2.5. Federated Learning and Distributed Intelligence

Federated learning (FL) offers a potential mechanism for distributed model development in IoV environments by allowing participating clients to exchange model information rather than centralizing raw observations [14,17]. This can be attractive when vehicular or institutional information is privacy-sensitive.

Its applicability is nevertheless constrained by non-IID data, mobility, intermittent participation, the communication overhead, computational heterogeneity, privacy and security threats, and convergence behavior [14,46]. Consequently, FL is treated in this study as a prospective extension rather than a core element of the Phase I architecture. A centralized predictive baseline should first be established before distributed alternatives are evaluated.

2.6. Comparative Analysis and Research Gap

The reviewed literature provides substantial evidence for the individual technological components required by an IoV-MEC-AI road safety architecture, but existing studies differ substantially in their objectives, datasets, geographic contexts, sensing infrastructures, communication technologies, hardware platforms, predictive targets, and evaluation procedures. A direct comparison of their reported numerical metrics is therefore methodologically inappropriate for estimating the performance of the proposed framework.

Table 1 summarizes representative studies according to their technological contributions, relevance to the proposed architecture, and principal limitations with respect to the target application.

Table 1. Representative related work and its relevance to the proposed IoV-MEC-AI framework.

Study	Focus/Approach	Relevance	Main Limitation
Butt et al. [4]	Wireless technologies and multimodal sensing for connected vehicles	Supports heterogeneous sensing and vehicular communication	No corridor-specific predictive edge–cloud architecture
Reddy and Muralidhar [17]	ML/DL and federated learning for IoV road safety	Supports predictive and distributed learning concepts	Review-level evidence without integrated deployment
Al-Najjar et al. [21]	LTE/NR-V2X resource allocation	Identifies mobility, congestion, interference, latency, and reliability constraints	Addresses radio-resource management rather than integrated risk assessment
Visconti et al. [31]	IoV smart road sensing and monitoring	Supports heterogeneous sensing, AI monitoring, V2I, and edge processing	No integrated predictive validation for a mountainous corridor
Yu [7]	YOLOv8-based traffic monitoring	Supports vehicle detection and traffic state feature extraction	Performance remains environment- and camera-dependent
Wang et al. [6]	GNN-LSTM crash risk modeling	Supports spatiotemporal representation and imbalance-aware learning	Different dataset and no IoV/MEC integration
Jadhav et al. [9]	Attention–LSTM traffic event modeling	Supports sequential modeling and temporally separated evaluation	Addresses event classification rather than integrated road safety architecture
Chaurasia et al. [45]	Hybrid edge–cloud processing	Supports separation of latency-sensitive edge and centralized computation	Performance depends on hardware and application configuration
Alsamiri and Alsubhi [14]	Federated learning in IoV	Supports privacy-aware distributed intelligence	Focused on cybersecurity rather than crash risk modeling
Proposed framework	Three-layer IoV-MEC-AI ex ante architecture	Integrates sensing, YOLOv8, MEC/V2X, CNN-LSTM, and institutional information	Corridor-specific system performance remains to be experimentally established

The central research gap is therefore architectural and contextual rather than algorithmic. The individual technologies are established, but the reviewed evidence does not provide an integrated architecture combining heterogeneous roadside and vehicular sensing, edge-based perception, V2X communication, spatiotemporal crash risk estimation, and Ecuadorian institutional information under the operational constraints of a high-demand mountainous corridor.

Three associated conditions remain particularly relevant. First, communication feasibility depends on end-to-end latency, reliability, availability, mobility, congestion, and LOS/NLOS behavior rather than on nominal radio performance alone [5,21,22]. Second, predictive feasibility depends on the construction of spatially and temporally harmonized multimodal data and on validation procedures that preserve the structure of the road risk problem [6,7,9]. Third, institutional deployment requires compatible data definitions, interfaces, access arrangements, and governance mechanisms.

Taken together, the literature supports the technical plausibility of the proposed IoV-MEC-AI architecture while leaving its integrated, corridor-specific behavior unresolved. This evidence provides the basis for specifying the architecture and the measurable requirements to be evaluated in the subsequent controlled validation stage.

3. Case Study

3.1. Study Area and Road Safety Context

The General Rumiñahui Highway is a high-demand road corridor in the metropolitan area of Quito, Ecuador. Along an approximately 10 km segment, it connects Quito with the eastern valleys and accommodates heterogeneous traffic flows under challenging roadway and environmental conditions. Steep gradients, sharp curves, high-speed sections, variations in traffic density, and changing weather and visibility make the corridor a relevant context for evaluating proactive road safety technologies.

Road safety on the corridor forms part of a broader metropolitan and national challenge. According to the Metropolitan Transit Agency (AMT), 16 road traffic crashes were reported on the General Rumiñahui Highway between January and June 2024, resulting in six injuries and two fatalities, with excessive speed identified as a leading contributing factor [47]. At the national level, the INEC reported 4789 crashes, 4032 injuries, and 603 on-site fatalities during the first quarter of 2026 [48]. Historical INEC statistics from 2024 [49] additionally provide context for the evolution of national road traffic fatalities across the reporting periods considered in Figure 2.

Figure 2. Reported road traffic fatalities in Ecuador for selected reporting periods from 2023 to 2026. The 2026 value represents a partial-year reporting period.

Figure 2 provides additional national context by showing the reported road traffic fatalities for selected reporting periods from 2023 to 2026. Because the 2026 value corresponds to a partial-year period, it should not be interpreted as directly comparable with complete annual totals. The figure is included solely to contextualize the persistence of road traffic mortality and is not used as an empirical input to the proposed framework.

As illustrated by the corridor characteristics and the broader safety context summarized in Figure 2, preventive mechanisms must operate under conditions in which the roadway geometry, traffic demand, speed, and environmental variability may reduce the time available to identify and respond to hazardous situations. The General Rumiñahui Highway is therefore used in Phase I as the target context for assessing the technical and contextual feasibility of an IoV-MEC-AI architecture capable of supporting future real-time crash risk estimation and preventive alerting. It is not treated as an instrumented experimental testbed in the present study.

3.2. Operational and Institutional Context

The operational environment of the General Rumiñahui Highway involves multiple institutions with responsibilities for roadway operation, traffic management, crash reporting, infrastructure maintenance, mobility planning, and emergency response. The corridor is under the jurisdiction of the Prefecture of Pichincha and is operated by the Corporación Autopista del Valle, while relevant information is also generated by organizations such as the Metropolitan Transit Agency (AMT), the National Transit Agency (ANT), ECU 911, the National Institute of Statistics and Census (INEC), the Ministry of Infrastructure and Transport (MIT), and the Metropolitan Public Mobility and Public Works Company (EPMMOP).

This distributed institutional structure represents an important contextual constraint. Relevant data may differ in geographic granularity, temporal resolution, update frequency, semantic definitions, formats, and access conditions. Consequently, a future IoV-MEC-AI deployment would require common spatial, temporal, and semantic references, together with mechanisms for interoperable information exchange among mobility, roadway management, infrastructure, and emergency response stakeholders.

This requirement is consistent with ISO 37106:2021, which emphasizes interoperable operating models and the reduction of organizational silos in smart city environments [15]. ISO 37122:2019 additionally provides mobility-related indicators that can guide the definition of monitoring and early warning capabilities [16]. In this study, these standards are used as architectural references; they do not imply that the identified institutions currently operate through a unified interoperable platform.

3.3. Candidate Institutional Data Sources

The ex ante assessment also examines whether information that is potentially relevant to crash risk analysis exists within the Ecuadorian institutional context. Six candidate sources were identified according to their possible contributions to historical risk characterization, traffic state estimation, emergency event analysis, and roadway context modeling.

These sources are considered candidate institutional data sources rather than a unified dataset available for model training. During Phase I, none was used to train, calibrate, test, or empirically validate the CNN-LSTM model or the complete IoV-MEC-AI architecture.

Table 2 summarizes the institutions, the general types of information that they provide, representative recent statistics, and their potential analytical roles in subsequent validation stages.

Table 2. Candidate institutional data sources and their potential analytical roles in subsequent validation phases.

Institution	Data Type	Representative Information	Potential Analytical Role	Reference
INEC-ESTRA	Statistical/Quarterly	Q1 2026: 4789 crashes, 4032 injured persons, and 603 on-site fatalities	Historical crash information for risk label construction and temporal analysis	[48]
ANT-Open Data	Georeferenced/Periodic	January–October 2025: 16,808 crashes and 1933 fatalities nationally; Pichincha: 3748 crashes and 369 fatalities	Georeferenced crash data for segment-level historical risk characterization	[50]
ECU 911	Operational/Near-Real-Time	2025: 3,239,683 national alerts, including 397,775 related to traffic and mobility	Emergency event information for temporal patterns and event prioritization	[51]
AMT-Quito	Road-Specific/Operational	General Rumiñahui Highway: 16 crashes between January and June 2024, including two fatalities	Corridor-specific traffic, crash, and video information	[47]
MIT	Infrastructure/Annual	By the end of 2025, 59% of the road network was reported to be in regular or poor condition	Roadway condition information for contextual characterization of segment-level risk	[52]
EPMMOP/Quito	Road Infrastructure/Annual	2026 projection: intervention on 3772.50 km of metropolitan road network	Road maintenance indicators for characterizing changes in roadway conditions	[53]

As summarized in Table 2, the identified sources are complementary but differ in analytical purpose and potential readiness for predictive modeling. The INEC and ANT primarily provide historical crash-related information; ECU 911 contributes operational incident information; AMT provides more corridor-relevant traffic and crash information; and MIT and EPMMOP contribute roadway and infrastructure contexts.

Their existence, however, does not imply immediate interoperability or suitability for model training. Future use will depend on accessibility, historical continuity, completeness, geographic precision, timestamp consistency, semantic compatibility, and data sharing arrangements. A more detailed classification of candidate variables, sources, and intended analytical uses is provided in Appendix A.

3.4. Data Integration and Preparation Requirements

The future use of the candidate institutional and sensing sources requires spatial, temporal, and semantic harmonization before predictive modeling can be performed. Spatially, crash events, traffic observations, infrastructure records, environmental measurements, and perception outputs must be associated with a common road representation. A segment-level representation is considered suitable for the proposed framework, although the final segmentation criterion and segment length must be established during Phase II according to the roadway geometry, sensing coverage, traffic behavior, and data availability.

Temporal integration requires a common timestamp convention and consistent observation windows because the candidate sources operate at different frequencies. High-frequency traffic, telemetry, environmental, and computer vision observations would need to be aggregated within defined temporal windows, whereas slower-changing contextual variables such as the roadway geometry, pavement condition, or maintenance status could be associated with their corresponding segments and periods of validity. Semantic harmonization would additionally require category mapping, duplicate detection, missing value treatment, unit normalization, consistency checking, and the verification of geographic and temporal validity [6].

The resulting information should distinguish relatively stable contextual variables from dynamic observations. Historical crashes, roadway geometry, pavement condition, and maintenance records would characterize the baseline segment conditions, whereas traffic states, vehicle behavior, environmental measurements, operational events, and YOLOv8-derived features would represent dynamic conditions. All sources would therefore require a common segment–time reference before multimodal observations could be combined for predictive analysis.

Detailed sample construction, feature selection, target definition, class imbalance treatment, prediction horizons, and temporal or spatiotemporal train–validation–test partitioning are specified as part of the predictive model methodology. These procedures were not implemented during Phase I: no unified institutional dataset was constructed, georeferenced, synchronized, or divided into training, validation, and test subsets. Their implementation constitutes a requirement for the subsequent controlled evaluation stage.

3.5. Scope and Limitations of the Ex Ante Case Study

The General Rumiñahui Highway is used as the contextual basis for an ex ante technical and contextual feasibility assessment, not as an instrumented experimental testbed. Accordingly, the present study does not provide corridor-specific measurements of the YOLOv8 detection accuracy, CNN-LSTM predictive performance, MEC/V2X latency, packet delivery reliability, service availability, or preventive effectiveness.

The principal limitations concern the heterogeneity of literature-based evidence, the absence of a unified institutional dataset, unverified corridor-specific communication and predictive model parameters, and unresolved institutional interoperability and governance arrangements. These limitations define the requirements for the subsequent controlled evaluation of the architecture rather than invalidating its use as a feasibility framework.

Phase II will therefore evaluate the proposed architecture through a digital twin of the General Rumiñahui Highway under controlled traffic, sensing, environmental, computational, and communication conditions. The resulting evidence will be used to refine the architectural parameters and performance requirements before a subsequent instrumented field pilot evaluates the framework under actual roadway and institutional conditions.

4. Methodology/Proposed Approach

4.1. Research Design and Ex Ante Feasibility Assessment

This study follows an architecture-centered ex ante feasibility assessment corresponding to Phase I of a staged validation process. Its objective is to determine whether the proposed IoV-MEC-AI framework is sufficiently supported and specified to justify progression toward controlled experimental evaluation.

The assessment combines three complementary evidence streams.

• Literature-based technical evidence: Previous IoV, V2X, computer vision, spatiotemporal modeling, and MEC studies are used to assess technological maturity, applicability, and known limitations.
• Context-specific evidence: Roadway characteristics, operational constraints, institutional conditions, and candidate Ecuadorian data sources are examined to determine whether the architecture can be meaningfully adapted to the General Rumiñahui Highway.
• Architecture-level requirements: Functional interfaces, data flows, processing responsibilities, communication constraints, interoperability conditions, and candidate performance indicators are specified as requirements for subsequent validation.

The methodological procedure comprises four stages. First, functional and contextual requirements are derived from the literature and the case study conditions. Second, these requirements are mapped to the three architectural layers and their corresponding processing responsibilities. Third, the technical and contextual feasibility of the proposed functions is assessed using the available evidence. Finally, unresolved assumptions, dependencies, and performance requirements are identified as inputs for Phase II validation.

The complete Phase I methodological workflow is summarized in Figure 3. The literature evidence, corridor-specific context, and architecture-level requirements constitute the main methodological inputs and are progressively transformed into architectural specifications, feasibility classifications, and testable requirements.

Figure 3. Phase I ex ante feasibility assessment workflow for the proposed IoV-MEC-AI framework. Literature-based evidence, corridor-specific information, and architectural requirements are transformed into feasibility classifications and validation requirements for Phase II.

As illustrated in Figure 3, Phase I does not attempt to demonstrate system performance. Instead, it transforms the available technical and contextual evidence into an explicit architecture specification and a set of measurable requirements for controlled evaluation.

The quantitative values reported in previous studies, including F1-scores, mAP values, inference times, end-to-end latency, and communication reliability, are therefore treated as cross-study feasibility evidence and candidate reference requirements rather than as indicating the measured or expected performance of the proposed framework. No corridor-specific predictive model, perception module, or communication subsystem is empirically evaluated during Phase I.

4.2. Proposed Three-Layer IoV-MEC-AI Architecture

The proposed framework follows a three-layer architecture that separates data acquisition, latency-sensitive edge processing, and cloud-based spatiotemporal risk analytics. This functional separation is intended to reduce the unnecessary transmission of high-volume raw data, support the local processing of time-sensitive information, and reserve cloud resources for historical integration and predictive analysis.

Layer 1 generates raw and structured observations from roadside, vehicular, and environmental sources. Layer 2 transforms these observations through MEC-enabled preprocessing, visual perception, multimodal feature fusion, event prioritization, and V2X communication. Layer 3 combines the resulting features with historical and contextual information to estimate the future segment-level crash risk and support preventive alert decisions.

Figure 4 summarizes the proposed architecture and its principal information flows.

Figure 4. Proposed three-layer IoV-MEC-AI architecture and information flow for crash risk estimation and preventive alerting.

As shown in Figure 4, sensing and data acquisition are separated from latency-sensitive MEC processing and cloud-based predictive analytics while preserving an end-to-end information path for preventive alert generation and dissemination.

4.2.1. Layer 1—Data Acquisition

Layer 1 defines the sensing interface of the framework. Its purpose is to acquire multimodal observations describing traffic, vehicle dynamics, the roadway context, and the environmental conditions. Candidate sources include the following.

• Roadside IP cameras: Timestamped video streams from operationally relevant road segments for downstream visual perception.
• Vehicular IoV sensors: OBD-II, MEMS, and GNSS/GPS information, including speed, acceleration, deceleration, braking, heading, and position.
• Environmental and roadway sensors: Measurements related to visibility, temperature, humidity, precipitation-related conditions, and pavement state.
• Roadside communication units: RSUs or equivalent gateways responsible for receiving local vehicular and sensing information and forwarding it to MEC resources.

Each observation should include at least a timestamp, spatial identifier, source identifier, measurement type, and quality or status information to support subsequent synchronization, georeferencing, and sensor fusion.

The Layer 1 output is represented as

$${\mathcal{D}}_{L1}=\{D_{\mathrm{video}},D_{\mathrm{vehicle}},D_{\mathrm{environment}},D_{\mathrm{road}}\},$$

which constitutes the multimodal input to the MEC processing layer. The sensing density, device placement, sampling frequency, and hardware configuration remain parameters for subsequent controlled evaluation.

4.2.2. Layer 2—Edge Processing, MEC, and V2X Communications

Layer 2 performs latency-sensitive processing close to the data sources. MEC resources support local preprocessing, perception, feature extraction, multimodal fusion, event prioritization, and the dissemination of time-sensitive safety information.

The edge processing sequence comprises the following:

1.

The reception and timestamp verification of Layer 1 observations;

2.

Preprocessing and quality control;

3.

YOLOv8-based vehicle and road user detection;

4.

The extraction of traffic state and perception features;

5.

The fusion of visual, vehicular, and environmental information associated with the same road segment and temporal interval;

6.

The prioritization of local safety events and forwarding of structured features to the predictive layer.

The resulting segment-level representation is

$${\mathbf{z}}_{s,t}=[f_{s,t}^{\mathrm{vision}},f_{s,t}^{\mathrm{traffic}},f_{s,t}^{\mathrm{vehicle}},f_{s,t}^{\mathrm{environment}}],$$

where s denotes the road segment and t is the observation interval.

Safety-critical events identified locally may be disseminated directly through the MEC/V2X subsystem, whereas structured feature vectors are forwarded to Layer 3 for prospective risk estimation. The framework remains independent of a specific radio-access technology; communication modes, candidate access technologies, latency, reliability, and availability requirements are specified in Section 4.5.

4.2.3. Layer 3—Cloud-Based Predictive Analytics

Layer 3 performs historical integration and spatiotemporal crash risk analysis. It receives the structured dynamic features generated by Layer 2 and combines them with historical and contextual information such as crash records, roadway characteristics, infrastructure conditions, and temporally aligned institutional variables.

The predictive component is specified as a CNN-LSTM architecture. The CNN is intended to extract local relationships among spatially organized segment features, whereas the LSTM models temporal dependencies across consecutive observation windows.

For road segment s and future time $t+H$, the principal output is

$${\widehat{p}}_{s,t+H}=P(Y_{s,t+H}=1\mid {\mathbf{X}}_{s,t}),$$

where ${\mathbf{X}}_{s,t}$ represents the sequence of harmonized observations available up to time t, and H is the prediction horizon.

The resulting probability is mapped to an operational risk category,

$${\widehat{p}}_{s,t+H}⟶\{\mathrm{Low},\mathrm{Moderate},\mathrm{High},\mathrm{Critical}\},$$

and may generate a structured preventive alert instruction for dissemination through MEC/V2X nodes, variable message systems, or authorized institutional services.

4.3. End-to-End Functional Workflow and Module Interfaces

The end-to-end workflow connects sensing, MEC-based perception and feature fusion, predictive analytics, risk decision-making, and alert dissemination. All exchanged records preserve a common road segment identifier, timestamp, source identifier, and quality metadata to support spatial and temporal alignment.

Layer 1 provides multimodal observations, while Layer 2 transforms these observations into the structured representation ${\mathbf{z}}_{s,t}$. Local safety-critical events may trigger immediate MEC/V2X dissemination, whereas structured feature vectors are forwarded to Layer 3 for prospective crash risk estimation. This distinction separates reactive local event handling from predictive risk assessment.

Layer 3 combines the edge-derived features with harmonized historical and contextual information, estimates the future crash risk probability, maps the result to an operational risk category, and generates an alert object when required.

Detailed definitions of the logical interfaces, including producers, inputs, outputs, consumers, spatial–temporal references, and the alert message structure, are provided in Appendix C. Communication-specific latency, reliability, and availability requirements are defined in Section 4.5.

4.4. Crash Risk Model Specification

The predictive component of Layer 3 is specified as a segment-level spatiotemporal CNN-LSTM model. Its objective is to estimate the probability of a predefined road safety event occurring within a future prediction horizon using temporally ordered observations from the target road segment and its local spatial context.

4.4.1. Spatial and Temporal Analysis Units

The basic spatial unit is a road segment s of the General Rumiñahui Highway. Segment boundaries should reflect operationally relevant changes in roadway geometry, access points, curves, intersections, sensing coverage, and infrastructure conditions.

Local spatial dependencies are represented through a neighborhood

$$\mathcal{N}\left(s\right)=\{s_1,\dots ,s_K\},s\in \mathcal{N}\left(s\right),$$

where K is the number of segments included in the spatial context. The composition of $\mathcal{N}\left(s\right)$ is determined by the roadway connectivity, geometry, access points, and sensing coverage.

Time is discretized using an aggregation interval $\Delta t$. For prediction time t, the model uses the preceding T intervals,

$$[t-(T-1)\Delta t,\dots ,t],$$

which define the observation window

$$W=T\Delta t.$$

The prediction horizon is denoted by H, with the model estimating the risk for

$$(t,t+H].$$

The parameters K, $\Delta t$, T, and H remain configurable and will be selected during the controlled evaluation according to the data resolution, roadway structure, sensing coverage, and predictive stability.

4.4.2. Input Features and Sample Construction

For segment s and time t, the feature representation is

$${\mathbf{x}}_{s,t}=[{\mathbf{x}}_{s,t}^{traf},{\mathbf{x}}_{s,t}^{vis},{\mathbf{x}}_{s,t}^{veh},{\mathbf{x}}_{s,t}^{env},{\mathbf{x}}_{s,t}^{road},{\mathbf{x}}_{s,t}^{hist},{\mathbf{x}}_{s,t}^{op}].$$

The candidate predictors are organized into the seven feature groups summarized in Table 3.

Table 3. Candidate feature groups for future CNN-LSTM model development.

Feature Group	Candidate Variables	Source
Traffic state	Flow, density, mean speed, speed variation, occupancy	YOLOv8/traffic sensors
Visual perception	Vehicle count, trajectories, stopped vehicles, anomalous maneuvers	YOLOv8/cameras
Vehicular dynamics	Speed, acceleration, deceleration, braking, heading	OBD-II/MEMS/GNSS
Environmental	Visibility, precipitation, temperature, humidity, pavement state	Environmental sensors
Road context	Curvature, slope, lane configuration, pavement condition	MIT/EPMMOP/road inventory
Historical safety	Crash frequency, severity, temporal crash patterns	INEC/ANT/AMT
Operational events	Emergency event frequency and temporal patterns	ECU 911/AMT

As summarized in Table 3, the predictive representation combines dynamic traffic, perception, vehicular, environmental, and operational observations with slower-varying roadway and historical safety information.

Dynamic variables are aggregated within the common interval $\Delta t$, whereas contextual variables are associated with their corresponding road segments and periods of validity.

The complete predictive sample for target segment s is represented as

$${\mathbf{X}}_{s,t}\in {\mathbb{R}}^{T\times K\times F},$$

where T is the number of temporal steps, K is the number of spatially related segments, and F is the number of input features.

Thus,

$${\mathbf{X}}_{s,t}=[{\mathbf{X}}_{t-T+1},\dots ,{\mathbf{X}}_t].$$

Missing value treatment, normalization, categorical encoding, and class imbalance correction must be estimated using the training partition only. Temporal or spatiotemporal train–validation–test partitions will be preferred over random observation-level splitting to reduce information leakage.

4.4.3. CNN-LSTM Input–Output Definition

The CNN-LSTM architecture separates spatial feature extraction from temporal dependency modeling. For each timestep $t_i$, the CNN receives

$${\mathbf{X}}_{t_i}\in {\mathbb{R}}^{K\times F},$$

and generates a spatial representation,

$${\mathbf{c}}_{t_i}=CNN\left({\mathbf{X}}_{t_i}\right).$$

The sequence of spatial embeddings,

$${\mathbf{C}}_{s,t}=[{\mathbf{c}}_{t-T+1},\dots ,{\mathbf{c}}_t],$$

is processed by the LSTM:

$${\mathbf{h}}_{s,t}=LSTM\left({\mathbf{C}}_{s,t}\right),$$

where ${\mathbf{h}}_{s,t}$ represents the learned temporal state.

A fully connected layer with sigmoid activation produces the future segment-level risk estimate,

$${\widehat{p}}_{s,t+H}=\sigma \left({\mathbf{W}}_o{\mathbf{h}}_{s,t}+b_o\right),$$

with

$$0\le {\widehat{p}}_{s,t+H}\le 1.$$

The supervised target is

$$y_{s,t+H}=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}\mathrm{a}\mathrm{qualifying}\mathrm{road}\mathrm{safety}\mathrm{event}\mathrm{occurs}\mathrm{in}\mathrm{segment}s\hfill \\ & \mathrm{during}(t,t+H],\hfill \\ 0,\hfill & \mathrm{otherwise}.\hfill \end{array}\right.$$

The operational definition of a qualifying event, including crash occurrence and severity criteria, must be harmonized across the institutional data sources before model training. This formulation is consistent with temporally ordered and spatiotemporal representations used in recent traffic risk studies [6,9].

No CNN-LSTM weights, hyperparameters, or performance metrics are estimated in Phase I.

4.4.4. Risk Score and Alert Decision Logic

The CNN-LSTM output is interpreted as a continuous crash risk estimate rather than as a deterministic prediction that a crash will occur. A threshold function maps the estimated probability to an operational category:

$$R_{s,t+H}=\left\{\begin{array}{cc}\mathrm{Low},\hfill & \widehat{p}<{\tau }_1,\hfill \\ \mathrm{Moderate},\hfill & {\tau }_1\le \widehat{p}<{\tau }_2,\hfill \\ \mathrm{High},\hfill & {\tau }_2\le \widehat{p}<{\tau }_3,\hfill \\ \mathrm{Critical},\hfill & \widehat{p}\ge {\tau }_3,\hfill \end{array}\right.$$

where

$$0<{\tau }_1<{\tau }_2<{\tau }_3<1.$$

The thresholds ${\tau }_1$, ${\tau }_2$, and ${\tau }_3$ are candidate operational parameters to be calibrated during Phase II, considering sensitivity, the false positive and false negative rates, class imbalance, and the operational cost of missed and unnecessary alerts.

The resulting alert object is represented as

$$A=\{s,t,H,\widehat{p},R,\mathbf{m}\},$$

where s identifies the road segment, t is the generation time, H is the prediction horizon, $\widehat{p}$ is the estimated probability, R is the assigned risk category, and $\mathbf{m}$ is the contextual metadata supporting the decision.

High- and critical-risk states may trigger preventive dissemination through MEC/V2X infrastructure, variable message signs, or authorized institutional services. The purpose is therefore preventive alerting based on the estimated crash risk, not deterministic accident prediction or demonstrated crash prevention.

4.5. V2X and MEC Communication Requirements

The communication subsystem connects vehicular, roadside, MEC, and cloud components and supports two traffic classes: latency-sensitive safety messages, which should be processed locally whenever possible, and non-critical analytical traffic, which may be forwarded to Layer 3.

4.5.1. Communication Modes and Access Technologies

The framework distinguishes V2V, V2I, and V2P communication modes from their underlying radio-access technologies, consistent with the V2X service management framework defined by ETSI/3GPP [54]. Table 4 summarizes the information exchanged, the candidate access technologies, and the functional roles of each mode.

Table 4. Candidate V2X communication roles and access technologies.

Mode	Primary Exchanged Information	Candidate Access Technology	Framework Role
V2V	Position, speed, trajectory, braking, and warning messages	DSRC/C-V2X/NR-V2X	Local cooperative safety messaging
V2I	Vehicle state, perception features, alerts, and infrastructure information	DSRC/C-V2X/NR-V2X	Vehicle–RSU–MEC communication
V2P	Risk and warning information involving vulnerable road users	Cellular/NR-V2X or supported short-range links	Preventive warning dissemination

As summarized in Table 4, the framework remains access-technology-agnostic. The final radio configuration will depend on the corridor coverage, infrastructure availability, mobility conditions, traffic demand, and service requirements.

Routing, handover, radio-resource allocation, interference mitigation, and medium-access mechanisms remain functions of the underlying communication infrastructure rather than contributions of the proposed framework. Their impact is represented through measurable latency, reliability, availability, and load requirements.

4.5.2. End-to-End Latency Budget

MEC is introduced to shorten the processing path of safety-critical information but does not imply zero-delay communication. End-to-end latency is defined as

$$T_{\mathrm{E}2\mathrm{E}}=T_{\mathrm{sense}}+T_{\mathrm{pre}}+T_{\mathrm{UL}}+T_{\mathrm{queue}}+T_{\mathrm{MEC}}+T_{\mathrm{decision}}+T_{\mathrm{DL}},$$

where $T_{\mathrm{sense}}$ is the sensing delay, $T_{\mathrm{pre}}$ is the preprocessing delay, $T_{\mathrm{UL}}$ is the uplink delay, $T_{\mathrm{queue}}$ is the MEC queueing delay, $T_{\mathrm{MEC}}$ is the edge processing time, $T_{\mathrm{decision}}$ is the decision generation delay, and $T_{\mathrm{DL}}$ is the downstream alert delivery delay.

For latency-sensitive safety messages, the candidate Phase II design objective is

$$T_{\mathrm{E}2\mathrm{E}}\le 100\mathrm{ms}.$$

This value is treated as a literature-informed design requirement rather than measured system performance. Phase II will quantify the individual latency components and determine whether the target remains achievable as the traffic density, wireless contention, and MEC computational load vary.

Cloud-based CNN-LSTM processing is not assigned the same sub-100 ms requirement because it supports prospective risk estimation rather than immediate local event dissemination. Its processing deadline should instead remain consistent with the selected observation interval and prediction horizon.

4.5.3. Reliability and Availability Requirements

Latency alone is insufficient for safety-oriented V2X operation. Message delivery must also remain reliable under mobility, rapidly changing topologies, congestion, interference, coverage variation, and LOS/NLOS propagation.

For safety message m, reliability is represented as

$$R_{\mathrm{msg}}=P\left(m\mathrm{is}\mathrm{correctly}\mathrm{delivered}\mathrm{within}{T}_{\mathrm{req}}\right),$$

while service availability is

$$A={\displaystyle \frac{T_{\mathrm{service}\mathrm{available}}}{T_{\mathrm{observation}}}}.$$

The candidate Phase II requirements are

$$R_{\mathrm{msg}}\ge 99.9\%,A\ge 99.9\%.$$

These thresholds are design targets whose adequacy must be experimentally evaluated rather than assumed for the General Rumiñahui Highway.

The principal communication indicators are the end-to-end latency, the packet delivery ratio within the required deadline, service availability, packet loss, the retransmission rate, the network load, the queueing delay, and performance degradation under mobility and LOS/NLOS transitions.

4.6. Feasibility Assessment Criteria

Phase I determines whether the proposed framework is sufficiently specified to progress toward controlled validation. Feasibility is assessed at the architectural and contextual levels rather than through measured system performance.

The assessment dimensions, criteria, evidence sources, and corresponding Phase I interpretations are summarized in Table 5.

Table 5. Criteria used for the ex ante feasibility assessment.

Dimension	Assessment Criterion	Evidence Considered	Phase I Interpretation
Sensing and perception	Availability of suitable sensing and visual perception technologies	IoV, sensor fusion, and YOLOv8 literature	Technical plausibility of Layer 1 and perception functions
Data	Availability and integrability of candidate variables	INEC, ANT, ECU 911, AMT, MIT, and EPMMOP sources	Contextual plausibility subject to harmonization and access
Predictive analytics	Suitability of spatiotemporal modeling for segment-level risk estimation	CNN-LSTM and related spatiotemporal studies	Methodological plausibility; empirical performance remains unverified
Communication	Ability of MEC/V2X configurations to satisfy candidate latency and reliability requirements	V2X and MEC literature	Conditional feasibility requiring controlled network evaluation
Interoperability	Compatibility with multi-institutional information exchange	ISO 37106:2021 and institutional context	Architectural requirement; organizational implementation remains unresolved
Operational readiness	Definition of interfaces, KPIs, risk outputs, and validation procedures	Phase I architecture specification	Readiness for controlled digital twin evaluation

As summarized in Table 5, the assessment distinguishes the technological precedent from conditions that still require experimental or institutional verification.

A criterion is classified as supported when the required function has an established technical precedent and no identified target-context constraint prevents its prospective use. It is conditional when feasibility depends on parameters that must be experimentally quantified, such as network coverage, data quality, latency, or predictive performance. A criterion is unresolved when essential evidence or implementation conditions remain unavailable.

The Results section applies this classification to the individual architectural dimensions.

4.7. Standards and Interoperability Alignment

ISO 37106:2021 and ISO 37122:2019 are adopted as design references for cross-domain integration, interoperability, and mobility-related performance monitoring [15,16]. Their relationship with the framework is summarized in Table 6.

Table 6. Standard alignment and corresponding framework requirements.

Standard	Applicable Principle	Framework Element	Intended Requirement
ISO 37106:2021	Smart operating models and cross-domain integration	Three-layer architecture and institutional interfaces	Support coordinated information exchange among mobility, roadway management, and emergency response actors
ISO 37122:2019	Smart city mobility indicators	Risk monitoring and evaluation functions	Provide measurable indicators for future assessment of mobility and road safety services

As shown in Table 6, ISO 37106:2021 primarily supports cross-domain integration and institutional interoperability, whereas ISO 37122:2019 provides a reference for mobility-related monitoring and evaluation requirements. These standards guide architectural design and do not imply formal certification or existing institutional interoperability.

Interoperability is considered at three complementary levels: syntactic, through common message structures and interfaces; semantic, through harmonized definitions of events, locations, timestamps, and risk variables; and organizational, through governance, responsibilities, and data sharing procedures among participating institutions.

4.8. Federated Learning as a Future Extension

Federated learning (FL) is retained as a prospective extension rather than a core component of the proposed framework. Its potential value lies in supporting distributed model training across vehicular, roadside, MEC, or institutional nodes while reducing the need to centralize raw observations [14,46].

Its applicability remains dependent on non-IID data, intermittent participation, mobility, the communication overhead, computational heterogeneity, convergence, privacy, and security constraints. FL should therefore be evaluated only after a centralized CNN-LSTM baseline has been established.

4.9. Phase II Digital Twin Validation Plan

Phase II will transform the architectural specifications and feasibility requirements established in Phase I into a controlled digital twin evaluation of the General Rumiñahui Highway. The objective is to evaluate the proposed IoV-MEC-AI framework under reproducible traffic, sensing, environmental, communication, computational, and crash risk conditions before an instrumented field deployment.

The digital twin will represent the relevant road geometry and segment structure together with the traffic demand, vehicular mobility, sensing coverage, environmental conditions, MEC resources, V2X communication behavior, and CNN-LSTM predictive workflow.

The evaluation will comprise four experimental blocks.

1.

Traffic and sensing evaluation: Variations in traffic density, vehicle speed, abnormal maneuvers, sensing coverage, visibility, and environmental conditions to assess perception and feature generation quality.

2.

MEC/V2X evaluation: Variations in vehicle density, network load, LOS/NLOS conditions, RSU coverage, packet loss, queueing, and MEC utilization to quantify communication reliability and end-to-end latency.

3.

Predictive model evaluation: Construction of temporally ordered segment-level samples and evaluation of the CNN-LSTM model using temporal or spatiotemporal train–validation–test partitions.

4.

Alert workflow evaluation: Assessment of the complete chain from sensing and risk estimation to threshold-based decision logic and preventive alert dissemination.

Predictive performance will be evaluated using

$$\mathrm{Precision},\mathrm{Recall},F1,\mathrm{AUC},$$

together with the false positive and false negative rates. Particular attention will be given to recall for high-risk events, because missed hazardous conditions have greater operational significance for preventive alerting.

Communication performance will be evaluated through

$$T_{\mathrm{E}2\mathrm{E}},R_{\mathrm{msg}},A,$$

together with the packet loss, retransmissions, queueing delay, and degradation under high mobility and LOS/NLOS transitions.

The experiments will systematically vary the traffic demand, sensing quality, prediction horizon, communication conditions, network load, and MEC computational resources. A sensitivity analysis will determine whether the candidate requirements remain achievable under degraded and high-demand conditions and will identify the parameters that most strongly influence the end-to-end performance.

Figure 5 summarizes the Phase II experimental workflow, linking the specifications produced during Phase I with the four validation blocks and their resulting refinement process.

Figure 5. Planned Phase II digital twin validation workflow. Phase I specifications are evaluated under controlled traffic, sensing, environmental, MEC/V2X, predictive model, and alert generation scenarios. The resulting evidence supports parameter refinement and the configuration of a subsequent instrumented field pilot.

As illustrated in Figure 5, the digital twin constitutes the intermediate validation stage between the Phase I architecture specification and field experimentation. It will provide controlled evidence for refining the model, communication, sensing, and alerting parameters before the framework is evaluated under actual roadway and institutional conditions.

Phase II will therefore provide controlled experimental evidence of system behavior but will not constitute final field validation. A subsequent instrumented pilot will remain necessary to integrate real sensor and institutional information, calibrate operational thresholds, and establish performance under actual operating conditions.

5. Results

5.1. Overall Ex Ante Feasibility Assessment

The ex ante assessment indicates that the proposed IoV-MEC-AI framework is technically plausible and contextually feasible under explicit conditions for the General Rumiñahui Highway. The assessment identifies an established technical precedent for multimodal sensing, YOLOv8-based perception, spatiotemporal risk modeling, and MEC-enabled vehicular communication, while corridor-specific data integration, communication behavior, institutional interoperability, and integrated system performance remain subject to further verification.

The principal outcome of Phase I is therefore not an empirical performance estimate but the determination of which architectural dimensions are sufficiently supported to proceed to controlled evaluation and which remain conditional or unresolved. The results are presented below in terms of component-level technical feasibility, contextual and data feasibility, consolidated feasibility classification, and readiness for Phase II.

5.2. Component-Level Technical Feasibility

Technical feasibility was assessed for three core technological dimensions: sensing and visual perception, spatiotemporal crash risk modeling, and MEC/V2X communication. Because the supporting studies were conducted under different datasets, hardware platforms, traffic environments, and communication configurations, their numerical results are interpreted as component-level feasibility evidence rather than as indicating the expected performance of the proposed framework.

Table 7 consolidates the representative evidence used to support these three technological dimensions.

Table 7. Representative literature-based evidence supporting component-level technical feasibility.

Component	Study/Approach	Evaluation Context	Reported Evidence	Feasibility Implication
Visual perception	Ugalino et al. [8]; YOLOv8 + ByteTrack	Real CCTV at two traffic monitoring sites	mAP50 = 0.91/0.89; counting error <3%	Supports roadside vehicle detection, tracking, and counting
Visual perception	Stiller et al. [13]; YOLOv8x	Open webcams under uncontrolled imaging conditions	F1-score = 0.75	Supports perception under heterogeneous imaging conditions
Visual perception	Yu [7]; optimized YOLOv8 + virtual induction loops	Complex urban traffic monitoring	Improved detection and temporal counting stability	Supports traffic flow and density feature extraction
Visual perception	Rey et al. [55]; YOLOv8n	Embedded Jetson Orin NX platform	52 FPS; 65 FPS with INT8	Supports edge-oriented visual inference
Spatiotemporal modeling	Wang et al. [6]; GNN-LSTM	US-Accidents dataset; spatiotemporal severity prediction	Weighted-F1 = 0.7923; Macro-F1 = 0.6587; AUC-PR = 0.7124	Supports spatial–temporal representation and imbalance-aware modeling
Spatiotemporal modeling	Jadhav et al. [9]; attention + LSTM	Sequential traffic event classification; unseen-day testing	Anomaly F1 = 0.81; AUC = 0.98	Supports temporal sequencing and testing on future unseen observations
MEC/V2X	Emara et al. [12]; cloud vs. MEC	Study-specific vehicular network configuration	Cloud: 300–400 ms; MEC: <100 ms	Supports shorter processing paths through MEC
MEC/V2X	Lucas-Estan et al. [11]; 5G V2N2V + MEC federation	Local peering and MEC federation	Latency below 100 ms under evaluated conditions	Supports conditional low-latency vehicular services
MEC/V2X	Coll-Perales et al. [44]; 5G V2X edge/cloud placement	Alternative service placement configurations	Lower delay with edge service placement	Supports edge placement for latency-sensitive functions
MEC/V2X	Mohammed et al. [10]; C-V2X + MEC	Radio- and MEC-dependent configuration	Additional latency reduction with edge integration	Supports combined V2X-MEC processing

As summarized in Table 7, the literature provides a technical precedent for each core component of the proposed architecture. YOLOv8-based systems support the extraction of traffic and perception features, but their applicability remains dependent on the corridor-specific illumination, visibility, occlusion, camera placement, traffic density, and hardware configuration.

The spatiotemporal modeling evidence supports the combination of spatial or contextual information with temporally ordered observations and also demonstrates the importance of class imbalance and temporally separated evaluation. These results support the methodological selection of the proposed CNN-LSTM formulation, while its actual feature representation, prediction horizon, calibration, and generalization remain to be established using corridor-relevant data.

MEC/V2X evidence similarly supports edge-oriented processing as a mechanism for reducing communication and processing paths. However, the reported latency values do not establish corridor performance. The end-to-end delay, message reliability, service availability, network load, mobility, coverage, and LOS/NLOS behavior remain deployment-dependent variables for controlled evaluation.

5.3. Data and Contextual Feasibility

The institutional analysis identified information sources covering the principal data categories required by the proposed framework. As summarized previously in Table 2, the INEC and ANT provide historical crash-related information, ECU 911 contributes operational incident information, AMT provides more corridor-relevant traffic and crash information, and MIT and EPMMOP provide roadway and infrastructure contexts.

This result supports the contextual feasibility of assembling a future multimodal information base, but not the immediate availability of a training-ready dataset. The identified sources differ in spatial granularity, temporal resolution, semantic structure, accessibility, continuity, and institutional ownership. Data feasibility is therefore classified as conditional on the verification of access and completeness and on successful spatial, temporal, semantic, and quality harmonization.

The relevant result is thus the identification of potentially sufficient information categories and institutional sources, while their actual compatibility and suitability for CNN-LSTM development remain to be established during subsequent data integration and controlled evaluation.

5.4. Feasibility Classification and Unresolved Conditions

The component-level and contextual findings were consolidated using the supported, conditional, and unresolved criteria defined in the methodology. Table 8 presents the resulting classification.

Table 8. Consolidated ex ante feasibility classification and unresolved conditions.

Dimension	Status	Basis for Classification	Unresolved Condition
Sensing and perception	Supported	Established roadside, vehicular, and YOLOv8-based sensing and traffic monitoring precedent	Corridor-specific device placement, coverage, illumination, occlusion, weather, and hardware robustness
Data integration	Conditional	Relevant complementary institutional and sensing data categories identified	Accessibility, completeness, georeferencing, temporal synchronization, semantic harmonization, and quality
Predictive analytics	Supported	Established spatiotemporal deep learning precedent	Training, target calibration, class imbalance, prediction horizon, threshold selection, and generalization
MEC/V2X communication	Conditional	Literature supports edge processing and latency-sensitive vehicular services	End-to-end latency, reliability, availability, mobility, congestion, coverage, and LOS/NLOS behavior
Institutional interoperability	Conditional	ISO-aligned architectural requirements and complementary institutional roles	Governance, common interfaces, responsibilities, access control, and data sharing arrangements
Controlled validation readiness	Supported	Architecture, variables, model specification, interfaces, communication requirements, and KPIs have been defined	Execution and refinement through the Phase II digital twin
Integrated framework performance	Unresolved	No common system-level controlled experiment has yet been conducted	Digital twin evaluation followed by instrumented field verification

As shown in Table 8, the assessment does not produce a binary feasible/not feasible conclusion. Instead, it distinguishes technological functions with sufficient precedent from deployment-dependent conditions that still require experimental or institutional verification. Sensing and perception, predictive analytics, and controlled validation readiness are supported at the ex ante level; data integration, MEC/V2X operation, and institutional interoperability remain conditional; and integrated framework performance remains unresolved.

No evidence considered in Phase I identified an inherent architectural incompatibility with the target corridor. Nevertheless, operational readiness and preventive effectiveness cannot be inferred until the conditional requirements and end-to-end system behavior are quantified.

5.5. Readiness for Phase II Digital Twin Validation

The Phase I results provide the principal inputs required for the controlled evaluation: the three-layer architecture, candidate variables, CNN-LSTM input–output specification, risk decision logic, module interfaces, MEC/V2X requirements, and candidate performance indicators.

These outputs support progression to the digital twin workflow illustrated in Figure 5, where the traffic demand, sensing quality, environmental conditions, mobility, network load, LOS/NLOS propagation, MEC utilization, prediction horizon, and alert thresholds can be systematically varied under nominal and degraded operating conditions.

Phase II is therefore expected to determine which candidate requirements remain achievable, identify failure conditions, and refine the sensing, communication, predictive model, and alerting parameters required to define a candidate configuration for subsequent instrumented field evaluation.

6. Discussion

The ex ante assessment indicates that the proposed IoV-MEC-AI framework is technically plausible and contextually feasible for the General Rumiñahui Highway under explicit deployment and validation conditions. The principal contribution is architectural and context-specific rather than algorithmic: established sensing, visual perception, edge computing, vehicular communication, and spatiotemporal modeling technologies are organized within the three-layer architecture shown in Figure 4 to address the roadway, communication, data, and institutional characteristics of the target corridor.

The component-level evidence summarized in Table 7 supports the technological choices underlying the architecture while also demonstrating why component maturity does not imply corridor-specific system performance. YOLOv8-based perception has sufficient technical precedent for extracting vehicle and traffic state information, and spatiotemporal deep learning approaches provide a methodological basis for segment-level crash risk estimation. Likewise, MEC/V2X studies support the use of edge processing for latency-sensitive vehicular services. However, perception robustness, predictive generalization, and communication behavior remain dependent on the operational conditions under which these components are integrated.

This distinction is reflected in the consolidated assessment reported in Table 8. Sensing and perception and spatiotemporal predictive analytics are supported by an established technical precedent, whereas institutional data integration, MEC/V2X operation, and interoperability remain conditional on corridor-specific and organizational verification. Integrated framework performance remains unresolved because the interaction among sensing, processing, communication, predictive analytics, and preventive alert dissemination has not yet been evaluated within a common experimental environment. The resulting classification therefore provides a more informative outcome than a binary feasible/not feasible judgment: it identifies both the architectural elements that are sufficiently mature to proceed and the conditions that must still be experimentally quantified.

Data integration is one of the main contextual dependencies. The identified Ecuadorian sources cover the principal information categories required for future multimodal road risk analysis, but their value depends on accessibility, completeness, geographic and temporal compatibility, semantic consistency, and data quality. The principal challenge is therefore not simply the existence of data but their transformation into a coherent segment–time representation that can support reliable predictive modeling. Institutional interoperability is closely related to this challenge. ISO 37106:2021 and ISO 37122:2019 provide useful references for cross-domain integration and mobility-related monitoring, but effective implementation still requires governance arrangements, common interfaces, data sharing mechanisms, and clearly assigned operational responsibilities [15,16].

Communication feasibility must also be interpreted conditionally. MEC can reduce the processing and communication paths for time-sensitive services, but it cannot by itself guarantee low end-to-end latency or reliable safety message delivery. Performance remains dependent on the network load, mobility, coverage, interference, computational utilization, and LOS/NLOS propagation. Routing and reliability studies provide complementary mechanisms for addressing these conditions: mobility- and link quality-aware geographic routing can improve forwarding robustness, grouped-RSU schemes can support routing under dynamic topologies, and IRS/STAR-RIS-assisted approaches can provide alternative multi-hop paths when direct LOS communication is obstructed [23,24,25,26,27]. These mechanisms are treated as candidate functions of the underlying V2X infrastructure and are not evaluated as contributions of the present architecture. Consequently, the latency, reliability, and availability requirements defined in the methodology should be understood as testable design targets rather than assumed properties of a future deployment.

Federated learning does not alter the Phase I feasibility conclusion because it is not required by the core architecture. Its relevance arises only if future deployment requires privacy-aware or decentralized model development across vehicular, roadside, MEC, or institutional participants. Establishing a centralized CNN-LSTM baseline first provides a clearer reference against which the predictive and communication trade-offs of distributed alternatives can subsequently be evaluated.

Taken together, the findings answer the research question at the feasibility level. The proposed hybrid IoV-MEC-AI framework has sufficient technical and contextual justification to progress toward controlled evaluation, but this conclusion should not be interpreted as demonstrated corridor-specific predictive accuracy, communication performance, operational readiness, or preventive effectiveness. The digital twin workflow shown in Figure 5 provides the appropriate next stage for evaluating these unresolved conditions under reproducible nominal and degraded scenarios. Its results will determine whether the candidate requirements remain achievable and will provide the evidence required to refine the architecture before subsequent instrumented field evaluation.

7. Conclusions

This study proposed a three-layer hybrid IoV-MEC-AI framework for future crash risk estimation and preventive alerting on the General Rumiñahui Highway and assessed its technical and contextual feasibility through an ex ante architecture-centered approach. The framework integrates multimodal sensing, YOLOv8-based visual perception, MEC/V2X processing, and CNN-LSTM-based spatiotemporal risk estimation within a context-specific architecture designed for the operational and institutional characteristics of the target corridor. The assessment indicates that the framework is technically plausible and contextually feasible under explicit conditions. An established technological precedent supports the proposed sensing, perception, predictive, and edge processing functions, while data integration, MEC/V2X behavior, and institutional interoperability remain conditional on corridor-specific verification. Integrated system performance remains unresolved until the complete sensing–processing–communication–prediction–alert chain is evaluated under a common experimental environment. The research question is therefore answered at the feasibility level: the available evidence justifies progression toward controlled validation but does not establish predictive accuracy, communication performance, operational readiness, or preventive effectiveness on the General Rumiñahui Highway.

The next stage will evaluate the framework through a digital twin of the target corridor under controlled traffic, sensing, environmental, computational, and communication conditions. This evaluation will refine the candidate architectural parameters, identify failure conditions, and determine whether the defined performance requirements remain achievable before an instrumented field pilot is conducted under actual roadway and institutional conditions. Federated learning may subsequently be investigated as a distributed learning extension after a centralized predictive baseline has been established.

Appendix B.1. Crash Risk Model Parameters

The principal spatial, temporal, feature, and decision parameters to be configured or calibrated during the controlled evaluation are summarized in Table A2.

Table A2. Candidate crash risk model parameters for controlled evaluation.

Parameter	Symbol	Role	Evaluation Treatment
Road segment	s	Basic spatial analysis unit	Defined according to geometry, access points, and sensing coverage
Spatial neighborhood	K	Number of target and related segments	Selected through sensitivity analysis
Aggregation interval	$\Delta t$	Temporal resolution of observations	Selected according to source resolution and model stability
Sequence length	T	Number of historical temporal steps	Evaluated experimentally
Observation window	$W=T\Delta t$	Total historical time represented by each sample	Derived from T and $\Delta t$ and evaluated for predictive stability
Prediction horizon	H	Future risk estimation interval	Evaluated as a configurable parameter
Feature dimension	F	Number of input features	Determined after data integration and feature selection
Risk thresholds	${\tau }_1,{\tau }_2,{\tau }_3$	Boundaries between low, moderate, high, and critical risk	Calibrated using predictive performance and false alert trade-offs

Table A2. Candidate crash risk model parameters for controlled evaluation.

Parameter	Symbol	Role	Evaluation Treatment
Road segment	s	Basic spatial analysis unit	Defined according to geometry, access points, and sensing coverage
Spatial neighborhood	K	Number of target and related segments	Selected through sensitivity analysis
Aggregation interval	$\Delta t$	Temporal resolution of observations	Selected according to source resolution and model stability
Sequence length	T	Number of historical temporal steps	Evaluated experimentally
Observation window	$W=T\Delta t$	Total historical time represented by each sample	Derived from T and $\Delta t$ and evaluated for predictive stability
Prediction horizon	H	Future risk estimation interval	Evaluated as a configurable parameter
Feature dimension	F	Number of input features	Determined after data integration and feature selection
Risk thresholds	${\tau }_1,{\tau }_2,{\tau }_3$	Boundaries between low, moderate, high, and critical risk	Calibrated using predictive performance and false alert trade-offs

As summarized in Table A2, Phase II does not assume fixed values for the principal spatial, temporal, or decision parameters. Instead, their configuration will be determined through the controlled evaluation and sensitivity analysis.

Appendix B.2. System Evaluation Indicators

Table A3 summarizes the principal predictive, operational, communication, computational, and propagation indicators required to evaluate the integrated framework.

Table A3. Candidate indicators and scenario variables for controlled system evaluation.

Dimension	Indicator/Variable	Symbol	Evaluation Role
Prediction	Precision, Recall, F1-score, AUC-PR	–	Assess predictive discrimination under imbalanced risk conditions
Operational	False positive and false negative rates	–	Support risk threshold calibration and alert performance analysis
Communication	End-to-end latency	$T_{\mathrm{E}2\mathrm{E}}$	Evaluate safety message delay and its component contributions
Communication	Deadline-constrained reliability	$R_{\mathrm{msg}}$	Measure successful message delivery within the required deadline
Communication	Service availability	A	Assess communication continuity under nominal and degraded conditions
Communication	Packet delivery ratio	PDR	Assess delivery robustness under mobility, congestion, and propagation changes
System load	Network load/MEC utilization	–	Evaluate queueing, contention, and computational effects
Propagation	Mobility and LOS/NLOS conditions	–	Evaluate communication robustness under corridor-relevant scenarios

Table A3. Candidate indicators and scenario variables for controlled system evaluation.

Dimension	Indicator/Variable	Symbol	Evaluation Role
Prediction	Precision, Recall, F1-score, AUC-PR	–	Assess predictive discrimination under imbalanced risk conditions
Operational	False positive and false negative rates	–	Support risk threshold calibration and alert performance analysis
Communication	End-to-end latency	$T_{\mathrm{E}2\mathrm{E}}$	Evaluate safety message delay and its component contributions
Communication	Deadline-constrained reliability	$R_{\mathrm{msg}}$	Measure successful message delivery within the required deadline
Communication	Service availability	A	Assess communication continuity under nominal and degraded conditions
Communication	Packet delivery ratio	PDR	Assess delivery robustness under mobility, congestion, and propagation changes
System load	Network load/MEC utilization	–	Evaluate queueing, contention, and computational effects
Propagation	Mobility and LOS/NLOS conditions	–	Evaluate communication robustness under corridor-relevant scenarios

As indicated in Table A3, the evaluation combines predictive quality with end-to-end communication and operational behavior. These indicators will be quantified while systematically varying the traffic demand, sensing quality, environmental conditions, network load, mobility, propagation conditions, and MEC computational utilization. The resulting sensitivity analysis will support the identification of failure conditions and the refinement of the candidate deployment configuration.

Appendix C.1. Logical Module Interfaces

The producer, information content, output, and consumer associated with each logical interface are summarized in Table A4.

Table A4. Logical module interfaces of the proposed IoV-MEC-AI framework.

Interface	Producer	Principal Input	Output	Consumer
$I_{1\to 2}$	Layer 1 sensing	Video, vehicular, environmental, and roadway observations	Timestamped and spatially referenced observations	MEC preprocessing
$I_{\mathrm{perception}}$	YOLOv8/sensor processing	Preprocessed sensing streams	Detections, counts, trajectories, and traffic state descriptors	Feature fusion
$I_{2\to 3}$	MEC fusion and prioritization	Multimodal dynamic features	Segment-level representation ${\mathbf{z}}_{s,t}$ and prioritized events	Cloud predictive analytics
$I_{\mathrm{context}}$	Context data integration	Crash, roadway, infrastructure, and operational information	Harmonized contextual features	Predictive input construction
$I_{\mathrm{risk}}$	CNN-LSTM model	Spatiotemporal sample ${\mathbf{X}}_{s,t}$	Crash risk estimate ${\widehat{p}}_{s,t+H}$	Risk decision module
$I_{\mathrm{alert}}$	Risk decision and alert generation modules	Risk estimate, threshold decision, and contextual metadata	Structured preventive alert message	MEC/V2X and authorized services

Table A4. Logical module interfaces of the proposed IoV-MEC-AI framework.

Interface	Producer	Principal Input	Output	Consumer
$I_{1\to 2}$	Layer 1 sensing	Video, vehicular, environmental, and roadway observations	Timestamped and spatially referenced observations	MEC preprocessing
$I_{\mathrm{perception}}$	YOLOv8/sensor processing	Preprocessed sensing streams	Detections, counts, trajectories, and traffic state descriptors	Feature fusion
$I_{2\to 3}$	MEC fusion and prioritization	Multimodal dynamic features	Segment-level representation ${\mathbf{z}}_{s,t}$ and prioritized events	Cloud predictive analytics
$I_{\mathrm{context}}$	Context data integration	Crash, roadway, infrastructure, and operational information	Harmonized contextual features	Predictive input construction
$I_{\mathrm{risk}}$	CNN-LSTM model	Spatiotemporal sample ${\mathbf{X}}_{s,t}$	Crash risk estimate ${\widehat{p}}_{s,t+H}$	Risk decision module
$I_{\mathrm{alert}}$	Risk decision and alert generation modules	Risk estimate, threshold decision, and contextual metadata	Structured preventive alert message	MEC/V2X and authorized services

Table A4 shows that the framework maintains a common information chain from multimodal sensing to preventive alert dissemination while separating perception, contextual integration, predictive analytics, and operational decision functions.

Appendix C.2. Edge and Cloud Decision Paths

The proposed framework defines two complementary processing paths, as shown in Figure A1. Safety-critical local events may be prioritized and disseminated directly through the MEC/V2X layer without waiting for cloud processing. In parallel, structured segment-level features are forwarded to Layer 3, where the CNN-LSTM model performs prospective crash risk estimation using dynamic and contextual information.

The edge path is therefore reactive and latency-sensitive, whereas the cloud path is predictive and supports future segment-level risk assessment. Both may converge on the same dissemination infrastructure, but they differ in processing latency, information requirements, and decision logic.

As illustrated in Figure A1, MEC supports both immediate local decision-making and the preparation of structured information for parallel cloud-based predictive processing.

Figure A1. Edge and cloud decision paths of the proposed IoV-MEC-AI framework. Local safety-critical events follow a direct MEC/V2X path, while structured features are processed in Layer 3 for prospective crash risk estimation and preventive alert generation.

Figure A1. Edge and cloud decision paths of the proposed IoV-MEC-AI framework. Local safety-critical events follow a direct MEC/V2X path, while structured features are processed in Layer 3 for prospective crash risk estimation and preventive alert generation.

Appendix C.3. Risk and Alert Representation

The predictive path provides the segment-level estimate ${\widehat{p}}_{s,t+H}$, which is converted into the configured operational risk category through the threshold logic defined in the methodology.

The resulting alert object is represented compactly as

$$A=\{s,t,H,\widehat{p},R,\mathbf{m}\},$$

where s identifies the affected road segment, t is the alert generation time, H is the prediction horizon, $\widehat{p}$ is the estimated crash risk probability, R is the assigned operational risk category, and $\mathbf{m}$ is the associated contextual metadata.

Appendix C.4. End-to-End Data Flow

Figure A2 summarizes the complete logical processing sequence from multimodal acquisition to preventive alert dissemination.

Accordingly, dynamic observations follow the sensing–MEC–predictive path, whereas historical and institutional information enters Layer 3 after spatial, temporal, and semantic harmonization. The resulting risk estimate is subsequently transformed into a preventive alert decision and returned to the dissemination layer.

Implementation-specific data formats, sampling rates, transport protocols, queueing policies, communication configurations, and operational thresholds remain parameters for controlled evaluation. Federated learning is excluded from this core data flow and remains a prospective distributed learning extension.

Figure A2. Logical end-to-end data flow of the proposed IoV-MEC-AI framework, from multimodal sensing and MEC processing to crash risk estimation and preventive alert dissemination.

Figure A2. Logical end-to-end data flow of the proposed IoV-MEC-AI framework, from multimodal sensing and MEC processing to crash risk estimation and preventive alert dissemination.