Intelligent Edge Computing Architecture: Low-Latency Transmission in an Intelligent Transport System for IoT Applications

Abstract

Latency is a determining factor in an IoT-enabled Intelligent Transportation System. To solve the latency issue in an edge computing system connected to the cloud, where the primary challenge is the distance between the end device and the cloud server, an implementation in a real urban environment is presented to illustrate the architecture of Intelligent Edge Computing. The IEC design is scalable through a communication system that incorporates latency and distance measurements in the transmission of a detection signal using deep learning at the edge node. This enabled the transmission of 2-byte detection signals to the fog node, where the received information was processed to count vehicles on up to three streets near the intersection. The vehicle detection signal is transmitted between two different embedded platforms. This architecture enabled an average transmission latency of 15.45 ms and a total end-to-end latency of 47.9087 ms over a distance of 600 m in a real-world urban environment. The IEC system leverages this low latency and offers intelligent processing closer to the data source and, therefore, to the user.

1. Introduction

Urban mobility is a critical challenge in modern cities that must be addressed carefully. The Intelligent Transportation System (ITS) aims to improve traffic efficiency through methods such as vehicle counting to estimate traffic levels at specific times, adjusting traffic light timings, and other measures [1,2,3]. In this context, the Internet of Things (IoT) has enabled technological advancement across various areas through cloud-based communication and the ability to present results to users. As a result of this communication, IoT generates a large volume of data, commonly sensitive and produced continuously, which requires fast and localized processing, as in the case of ITS applications [4]. The main challenge arises when the number of end devices connected to the sensors for data collection increases, and the user expects a response in the shortest possible time. Latency plays a crucial role in data transmission in IoT applications. This latency depends on user location, server distance, time of access, access technology, and network topology, among other factors [5]. The cloud computing process of receiving user data on centralized servers, processing it, and transmitting it back to the system for application decision-making places a considerable load on the network [6]. A notable factor is the physical distance between data centers, which directly impacts data transmission [7]. As a result, low efficiency is observed in latency-sensitive applications. Therefore, among the limitations of this type of architecture are high latency, network congestion, and increased risk to data confidentiality [4]. In this context, an improved network architecture of Edge Computing, which has shown substantial growth in recent years [8], enables enhanced response times in data communication with a server and incorporates deep learning models to support fast, efficient decision-making in data collection; this is Intelligent Edge Computing (IEC) [9]. IEC is a decentralized model that does not replace the fundamental network structure; instead, it enhances it with machine-learning capabilities that improve data analysis and decision-making without requiring a cloud connection [10,11]. Data is processed, stored, and analyzed near its source. This model comprises two nodes: the Edge node serves as a transmitter and the Fog node as a receiver for system control, both of which have been proposed as cloud extensions. In this case, more devices are interconnected in this architecture, enabling more efficient service with lower latency for a system dedicated to a specific task. This type of system is characterized by limited resources and a focus on accelerating sequential processing. The core idea behind IEC is to offload most processing to the Edge node, where Deep Learning runs to support decision-making in IoT applications.

The Fog node provides intermediate processing between the Edge nodes and the cloud [10]. Its proximity to the user reduces communication and response latency in IoT applications that do not require a cloud connection. The benefit of this connection is that the Edge node sends only what is necessary in a small packet. On the other hand, the Fog node avoids blocking due to recursive calls and manages memory more efficiently. IEC applies to dedicated systems that require a normal flow and instantaneous response, as in some IoT applications.

The main idea of this paper is to provide a solution to latency in end-to-end communication in IoT systems. The prototype is implemented using Fog Computing [9]. The controller is applied to an intersection in the City of Puebla, Mexico, to illustrate the performance of this approach using real traffic data from nearby streets. Our key contributions were as follows: (1) An Intelligent Edge Computing infrastructure to reduce the latency in an ITS for IoT systems. The proposed scalable architecture integrates up to three Edge nodes with a vehicle detection system based on Deep Learning, and a fog node to store data and control an ITS. The wireless communication link was implemented using the 802.15.4 standard [12] at 900 MHz. (2) Transmission latency and end-to-end latency measurements are mainly based on a distance of approximately 600 m in the IEC architecture. During the experiment, we used a high-bandwidth internet connection and a low-bandwidth IEC connection. In the case of cloud computing, latency is measured to a Google server using RTT, which includes propagation delays along the entire network path, as reported in [5]. At IEC, we primarily focus on latency between Edge and Fog nodes without acknowledgment (response), unlike ICMP. This is because IEEE 802.15.4 only has two layers: the Physical layer and the Media Access Control layer. The message to be transmitted is an alert or interruption from an ITS; therefore, the message size is small, which aligns with the Edge node’s purpose of extracting detection-system characteristics.

The paper was structured as follows: Section 2 reviewed existing research on ITS within edge computing and fog computing implementation. Section 3 detailed the architecture of IEC, describing the key modules and methodology. Section 4 provided experimental results, and Section 5 summarized the conclusions.

2. Literature Review and Background

2.1. Traffic Control

Traffic congestion in urban areas is a relevant topic for ITS, which is why ITS is necessary to solve problems such as dynamic traffic management to achieve smoother journeys on existing infrastructure. The author [13] designed a quasi-dynamic policy that controls traffic signal cycles using real traffic data from a simulated intersection. Author [14] applied a recently introduced adaptive method in the reinforcement learning (RL) literature, the ε-greedy, at an isolated intersection, and demonstrated that traffic delays were significantly reduced at different levels of demand. Author [15] proposed an Adaptive Traffic Signal System (ATLS) to predict traffic volume for the current time and day using machine learning in the SUMO simulation environment at an isolated intersection. In paper [16], a traffic signal control system was proposed with adaptive image processing based on deep learning for real-time dynamic signal regulation. The YOLOv10-based model was evaluated in SUMO and identified and classified vehicles, and a dynamic timing algorithm allowed continuous redistribution of green light durations. The author [17] implemented a real-time system on a Raspberry Pi using YOLOv8 for vehicle detection and distance estimation. This provides a scalable and affordable solution for traffic monitoring in resource-constrained environments. In [18], a novel, decentralized traffic signal control strategy was presented, the Tree Method, which demonstrated a significant ability to identify the main contributors to congestion, leading to improvements in performance and average travel times. The evaluation was conducted in SUMO. The author [19] proposed a hybrid AI model that combines convolutional neural networks (CNNs) for image-based traffic density estimation, LSTM networks for environmental time-series prediction, and RL for adaptive traffic light control. The implementation was carried out on a Raspberry Pi as edge computing to perform real-time processing and reduce latency. In paper [20], an Advanced Prevention Unit (APU) system was designed to mitigate accidents in mountainous regions. APU integrates Raspberry Pi with sensors to monitor traffic, detect violations, issue speeding alerts, and warn drivers of approaching vehicles on sharp curves. Author [21] defined a vehicle tracking system as a sequential decision-making process based on linear programming. The experiments were conducted using an NVIDIA GeForce RTX 3070 GPU and provided improved robustness and temporal continuity.

2.2. Vehicle Detection with Deep Learning

Real-time vehicle detection in ITS using images or videos poses a challenge for traffic improvement applications [22]. In paper [23], the problem of counting vehicles using computer vision through Deep Learning models is analyzed, and the results focus on determining the best model. In [24], a method is proposed to estimate traffic density and thus control traffic signal timing for effective traffic management. This is achieved through vehicle recognition and counting using deep learning technologies such as CNNs. Experimental results demonstrate that detection with thermal images was superior to that with visible images. Author [25] mentioned that vehicle detection remains a challenge in object recognition. The method proposed in this work is based on deep learning and edge detection. Edge detection is used in these functions to reduce the number of calculations. This method strikes a reasonable balance between speed and accuracy. Author [26] proposed the design of a self-adaptive real-time cruise control system to enable the tracking of the trajectory of autonomous land vehicles, so that an autonomous car can travel along a road while following a lead vehicle. In [27], they conducted research and designed a vehicle recognition algorithm and a road environment discrimination algorithm, which significantly improved the accuracy of vehicle detection on the road. They used a deep learning framework and trained a classification model to complete real-time road environment discrimination as a basic condition for vehicle and traffic recognition. Author [28] focused on vehicle and pedestrian detection, highlighting it as a critical task in autonomous driving. This article analyzes several conventional object detection architectures. Experiments revealed that SSD MobileNet V2 is the fastest (70 FPS) and SSD MobileNet V1 is the lightest in terms of memory usage, making them suitable for mobile and embedded applications. In [29], computer vision and real-time object detection techniques were applied to the Nvidia Jetson Nano card. The models used were MobileNet-SSD and YoloV4 to compare vehicle-counting performance. The results show that the MobileNet-SSD model achieves 40 FPS and is suitable for real-time applications. Compared to YOLOv4, the latter runs at a lower speed but can detect smaller objects. In [30], a dynamic traffic signal system was defined that estimates signal timing from dynamically changing traffic images along the road. Self-learning is achieved using the YOLO algorithm, which detects and counts the total number of vehicles on the avenues at a signalized intersection. The communication between traffic intersections and adjacent intersections is facilitated to transmit the observed cumulative traffic delay. Transmission is carried out using two technologies: the first, IEEE 802.15.4 in the 2.4 GHz band, using Raspberry Pi 4 Openlabs modules to communicate between traffic signals within the same intersection; and the second, LoRa in the 868 MHz band, using ESP32 modules to communicate between traffic signals at different intersections.

2.3. Edge and Fog Computing

Given the importance of quality of service and security in delay-sensitive requests, other innovator solutions, such as edge and fog computing, have also been introduced to accelerate processing, mitigate resource congestion, and manage sensor data in real-world scenarios [31,32,33,34]. In [35], the proposal was implemented as a prototype, an intelligent traffic monitoring system (STMS). This is done by a small module machine that represents the Fog node, with sensors distributed across the network, these collect real-time data and transfer it to the cloud, which processes and stores it. The results show that the Fog network improves the cloud platform’s performance, reducing response time and increasing bit rate. The Intel Edison kit for Arduino is used as hardware, and the WiFi standard is used for communication. In [36], a traffic signal controller powered by Smart Edge Computing (SEdge) is proposed that considers heterogeneous vehicle dynamics in real time at the Fog node. The Fog node runs the proposed fuzzy inference system to determine the phase cycle duration. Specifically, the queue-length-based traffic signal controller, using SEdge devices, detects whether a lane is starved and receives vehicles continuously during peak hours. SEdge is defined as a traffic signal controller designed to generate longer durations for each phase (green, yellow, red) based on the length of the lane queue. To validate the SEdge controller, a prototype of an Indian city is developed in OpenStreetMap, without specifying wireless communication, using low-power IoT devices such as Raspberry Pi and an open-source simulator. In [37], an adaptive traffic congestion management and control scheme based on the Internet of Vehicles and Fog Computing is proposed. The scheme consists of dividing an urban region into several traffic management areas, and when congestion occurs, the objective of fog servers is to control traffic signals in real time using established configurations, thereby enabling traffic flow. In [38], a cooperative framework is established for a smart traffic light controller based on deep reinforcement learning (DRL), integrated into a Fog Computing node via TCP/IP-based communication with the roadside cameras and the edge system. In [39], an Edge Computing-based data sensing scheme for traffic light intersections in a V2E network is proposed using an algorithm. In this scheme, traffic lights represent Edge nodes to detect vehicle data. Vehicle data is collected via V2E communication via the base station, and scenarios with multiple intersections are also considered. The solution derived from the experimental results, considering a large number of vehicles and complex data, was effective at identifying them. In [40], a Vehicular Edge Computing (VEC) model is presented that captures the specific temporal and spatial requirements of vehicular applications. Furthermore, a deadline-based strategy incorporating traffic light data is described to opportunistically offload tasks. The model allows up to 33% more tasks to be offloaded to roadside RSUs than the existing workload, without causing deadline breaches and maximizing the utilization of RSU resources.

3. Materials and Methods

The proposed IEC-based system for reducing transmission time in ITS for IoT applications combines hardware and software to detect vehicles using image acquisition and deep learning inference within an embedded system. The prototype detects vehicles on streets near an intersection, up to three streets near the intersection are considered as shown in Figure 1. The top section shows the distribution of nodes in the vehicle detection system implementation scheme, along with the input data and output signals of the Edge nodes and the central Fog node in one-way communication. The bottom section maps this physical hardware directly to the functional software hierarchy: the Edge nodes run localized AI inferences to send signals (S1, S2, S3) through XBee modules (Digi International, Hopkins, MN, USA); when the Fog layer asynchronously listens to these streams, the Fog node operates the global counter and sends timestamped event logs to an ITS. This example of a vehicle detection system allowed for measuring the link latency. Vehicle detection is performed at each Edge node using a deep learning model with the SSD-Mobilenet architecture [41,42]. The 2-byte detection signal is transmitted wirelessly via 802.15.4 at 900 MHz, and vehicles are counted upon reception of the signal at the Fog node.

The overall sequence-level procedure is summarized in Algorithm 1, and Figure 2 depicts the configuration flowchart for the developed system.

Algorithm 1. Operations executed by Edge and Fog nodes in an IEC system

Edge node (Camera/Local Processing)

INPUT: Detects vehicle on Signal 1, Signal 2, or Signal 3.

OUTPUT: Send detection signal S1, S2, or S3.

1 While TRUE

2   Current_detection = Do Detection system

3       If Current_detection == S1 Then send signal “S1

4       Else If Current_detection == S2 Then send signal “S2”

5       Else If Current_detection == S3 Then send signal “S3”

6 End While

Fog node (Traffic Controller (Application))

INPUT: Receive detection signal S1, S2, or S3.

OUTPUT: It counts the received signals but listens for detection signals that interrupt and records the event in the ITS application.

1 While TRUE

2         Do Main Counter

3         If signal received is True Then

4                  Increment counter and save (Log + Timestamp)

5         End If

6 End While

3.1. IEC Infrastructure

The infrastructure is established using Edge and Fog nodes, as shown in Figure 3. In the implementation, the Edge and Fog nodes were temporarily powered by a portable external battery (25,000 mAh, 145 W maximum output). The vehicle detection system runs on each Edge node using the Jetson Orin Nano board (NVIDIA Corporation, Santa Clara, CA, USA). The Fog node, installed on a Raspberry Pi 5 (Raspberry Pi Ltd, Cambridge, UK), stores data received from the Edge node without a cloud connection and manages the ITS control system under development. This establishes a decentralized infrastructure located at the network edge. These nodes are detailed below.

3.1.1. Edge Node

Edge computing focuses on local data processing, such as feature extraction, and on transmitting data across the network to a server. In this system, focused on an ITS application such as vehicle counting to improve traffic flow, the Edge node was equipped with Deep Learning capabilities to enhance its data analysis and decision-making capacity without requiring cloud connectivity. According to [10], the demand for moving intelligence from the cloud to an Edge device in applied research is attractive due to security, performance, bandwidth, and data integrity.

The Edge node was configured on the Jetson Orin Nano graphics card because it offers superior AI performance, with 67 TOPS (Tera Operations Per Second), which indicates the processor’s ability to execute AI operations per second. It has 8 GB of RAM and 6 cores. The use of CUDA cores on the card was crucial because it enabled the graphics card’s high computational power to accelerate certain tasks in parallel.

The neural network training was performed on the same Jetson Orin Nano board. The SSD Mobilenet [41,42] model was chosen for this prototype because it is an object detection model. The images selected for the training data were captured on streets and avenues in Puebla City, Mexico, as shown in Figure 4.

3.1.2. Fog Node

The Fog Node is considered the element that distributes administrative, storage, computing, and network functions to enable rapid responses to users due to its proximity to them [10]. The Fog node is located on the Raspberry Pi 5 board and comprises three main modules: data reception, vehicle counting, and storage. Therefore, this node receives S1, S2, or S3 signals from the Edge Node, counts them to determine the number of detected vehicles, and stores the counts in a database. Figure 5 shows the modules of each node.

3.1.3. Wireless Communication

With the rapid development of communication technologies and the high demand for data connectivity for IoT, smart cities, and artificial intelligence, networks are adapting to support the proliferation of these connections across multiple media. Personal Area Networks (WPANs) and Wireless Local Area Networks (WLANs) enable the establishment of topologies for data exchange using various standards. This work addresses 802.15.4 in the 900 MHz band, implemented at the MAC and PHY layers. To guarantee Quality of Service (QoS), the standard uses mechanisms such as GTS (Guaranteed Time Slots) in superframe mode, allowing the prediction and limitation of delays for critical applications. The Xbee PRO 900HP module was used to program the ADF023 transceiver in the unlicensed ISM band. This module was connected to both Edge and Fog nodes to transmit and receive signals detected from vehicles using dipole antennas.

4. Results and Discussion

4.1. Detection System

To perform real-time inference, a trained model is required. This is done on the Edge node of the Jetson Orin Nano board to comply with the IEC architecture. Therefore, we used our own set of street images from Puebla, Mexico. The total number of images used to train the network was 3307. It is important to note that more than one annotation was made for each image, regardless of whether the annotations belonged to the same class. Therefore, the total number of annotations was calculated, resulting in a total of 6200. The different vehicle classes present in the training set were car, bus, van, and motorcycle. Although the vehicle count only detects the presence of any vehicle, the count can be further refined. The SSD Mobilenet model was trained for 500 epochs on the Jetson Orin Nano card.

Table 1. Hyperparameters for training in the vehicle detection system.

SSD-Mobilenet
Phase	Parameter/Metric	Value
Dataset Profile	Total Training Images	3307
	Total Annotated Bounding Boxes	6200
Hyperparameters	Initial learning rate	0.01
	Batch size	4
	Epochs	500
	Optimizer	SGD (Momentum: 0.9, Weight Decay: 0.0005)
	Scheduler	Cosine
	Input resolution	300 × 300
Evaluation Metric	Global mAP	0.82
Compute environment	Hardware accelerator	CUDA 12.2.140 (NVIDIA ORIN 8G)

presents the hyperparameters used to train the model. At the end, the training data was saved in an open format defined by ONNX (Open Neural Network Exchange), which allows the model to perform inference without retraining, thereby facilitating compatibility with other infrastructures. Therefore, with the trained model in ONNX format, it can be run on other Jetson Orin Nano boards to perform inference on the previously trained model, thereby avoiding increased resource and time consumption on the hardware. Based on the detection performed, the signal to be sent wirelessly is determined. The system was evaluated in different scenarios. In Figure 6, (a) and (b) were considered in real-time outdoors, while (c) and (d) were considered throughout standardized, high-quality test sequences [43], demonstrating the system’s detection stability. In this prototype, three different streets near an intersection were considered. Each street is identified as Signal 1, Signal 2, and Signal 3. When a detection occurs on each street, the detection system sends signals S1, S2, and S3.

4.2. Vehicle Count

The Fog node on the Raspberry Pi 5 board receives signals from the detection system for each street. The vehicle counting module shows real-time accuracy; however, when two vehicles arrive at the detection system from a street simultaneously, the counting program exhibits inaccuracy due to the overlapping problem, as reported by [23]. The vehicle count results from the signals received on the three streets, as shown in

Table 2. Fog Node: Real-time vehicle detection and events recorded from Edge nodes in an IEC system.

Event ID	Timestamp (DD/MM/YY/hh:mm:ss)	Signal Source	Incoming Interrupt Signal	Cumulative Vehicle Count
1	12/03/26 10:17:19	Edge node 1	S1	88
2	12/0312/26 10:17:21	Edge node 2	S2	118
3	12/03/26 10:17:24	Edge node 3	S3	95

, were saved in the SQLite3-configured database.

4.3. Distance Reached

The experimental setting for the distance measurement tests was within the facilities of the Autonomous University of Puebla in Puebla, Mexico. The outdoor environment with a line-of-sight for the measurements is shown in Figure 7, the marked points indicate the final positions at which the 600 m measurement was obtained. Dipole antennas were used for transmission, achieving a line-of-sight. To collect data transmission, the Fog node was initially static to receive a signal in unicast mode from the Edge node, while the Edge node was moved to observe changes in communication between the nodes. We varied the distance in steps of 20 m until reaching 600 m between the nodes. Based on this, it is determined that the streets of Puebla City are 150 m to 270 m long, so the transmission of signals with this type of infrastructure can be carried out without problems.

This scenario allowed for other measurements such as RSSI and latency, which will be reviewed later. In the case of the RSSI, the module specifications are as follows: for the XBee-PRO 900HP module, RSSI measurements are accurate to −40 dBm up to the receiver’s sensitivity threshold. In our experiment, we report that, outdoors, within the measured range of approximately 150 m to 600 m, the RSSI value ranged from −40 dBm to −70 dBm, enabling successful communication. These results can be used to develop distance estimation applications for ITS, as described in [44].

4.4. Latency IEC and Cloud

Based on the same scenario described above, the experimental campaign for the latency, we performed 30 measurements over 3 days at different times to estimate the sending latency from the Edge node to the Fog node. Latency was measured considering three aspects: the local software stack, serialization delay, and propagation time over the wireless medium, including the IEEE 802.15.4 ACK (acknowledgment). This time was measured using the time.perf_counter() function, starting from when the 2-byte data is loaded into the Edge node’s XBee transmitter module, which modulates and transmits the signal. Due to the use of the IEEE 802.15.4 standard, a Layer 2 MAC ACK is expected from the Fog node’s XBee receiver module. Upon receiving this ACK, the transmission is complete, and the timer stops. Otherwise, if the XBee receiver module is idle or the channel fails, the ACK is not received, resulting in a communication exception at the Edge node. We reported that a certain stability in latency was observed as the devices moved further apart. Therefore, we set a distance of 600 m to collect latency data over three days. This is shown in Figure 8.

Table 3. Mean, standard deviation, maximum, and minimum of measured latency over three days.

	Mean (ms)	Std	Maximum (ms)	Minimum (ms)
Day 1	15.50	0.37	16.23	14.8
Day 2	15.44	0.26	15.86	15.04
Day 3	15.39	0.32	16.2	14.62
Total	15.45	0.32	16.23	14.62

summarizes the behavior of latency across the evaluated days, including its mean, standard deviation, as well as maximum and minimum values per day and across all measurements. We can observe that the difference between the maximum and minimum values for each day is 1.43 ms on day 1, 0.82 ms on day 2, and 1.58 ms on day 3. This indicates that on days 1 and 2, there were more non-fixed interferences. On the other hand, the total standard deviation is 0.32; this small value suggests that the system’s latency will stay close to the average.

In addition, the end-to-end latency of the IEC system is measured from frame capture to database data storage. The total end-to-end latency ($T_{IEC}$) considers four latency parameters as shown in

Table 4. End-to-end latency stages of the IEC architecture for vehicle detection.

Node	Parameter	Description	Latency (ms)
Edge (Jetson Orin Nano)	$T_{Capture}$	Frame acquisition from camera hardware	26.9
	$T_{CUDA}$	GPU Pre-process, Inference (FP16), Post-process	5.2
	$T_{Tx}$	900 MHz Wireless Transmission (incl. MAC ACK)	15.45
Fog (Raspberry Pi 5)	$T_{Fog}$	Serial read, packet parsing, and DB write	0.3587
Total System	$T_{IEC}$	End-to-End latency Cycle	47.9087

and Equation (1).

$$T_{IEC}=T_{Capture}+T_{CUDA}+T_{Tx}+T_{Fog}$$

(1)

where

• $T_{Capture}$: Frame capture time at the Edge node;
• $T_{CUDA}$: Total processing time of the CUDA-based detection system;
• $T_{Tx}$: Wireless transmission time over the 900 MHz link to the Fog node;
• $T_{Fog}$: Processing and database write-operation time at the node Fog.

In the Fog node, the time measurement was taken from the capture of the received 2-byte signal, followed by payload processing (including signal interpretation) and, finally, signal storage (recording the event timestamp and status data in the SQLite3 database). Storage in the SQLite3 database proved critical due to disk I/O. Therefore, to optimize it, non-blocking configurations were implemented by setting PRAGMA journal_mode = WAL and PRAGMA synchronous = OFF. Finally, after 50 experimental tests, the latency at the Fog node averaged 0.3587 ms.

Regarding cloud-to-user latency, we adopted an RTT-based testing method, as reported in [5], using the Internet Control Message Protocol (ICMP), the mean was close to 20 ms. The Google Cloud RTT (20 ms) was selected as a conservative, upper-bound baseline representing the absolute minimum network overhead of a centralized cloud solution. Additionally, the measured results accounted for physical distance, network congestion, and intermediary devices used to process the information. However, RTT is strictly a network-level metric that only measures packet transport. If we were to deploy this system in the cloud, the total cloud application latency would be the sum of the frame capture ($T_{Capture}$), CUDA processing ($T_{CUDA}$), and cloud database save times added to the baseline 20 ms RTT. Furthermore, a centralized cloud solution requires a bidirectional communication loop to send the detection response back to the local node, thereby triggering an action. In contrast, our proposed IEC architecture leverages a local, dedicated server with unidirectional communication. This allows the system to complete the entire pipeline locally in just 47.9087 ms. This clearly demonstrates that the IEC approach prevents the cumulative overhead that an equivalent cloud-based deployment would suffer.

In an edge computing system without AI, the latency between user data collection and the final system action is significant. The prototype presented in this letter proposes an Edge Computing Interface (IEC) in which the system itself performs decision-making and requires only a link with a mean latency of 15.45 ms.

Table 5. Practical parameters for low-latency transmission in an urban environment for an ITS.

IEC Architecture Parameters	Value
IEC communication range	600 m
Alert signal size	2-byte
Data transfer rate	200 kbps
Transmission latency from the Edge node to the Fog node	15.4 ms
RSSI	−40 dBm a −70 dBm

presents the most significant values for IEC implementation.

The results obtained were compared with the literature survey presented in the corresponding section of this letter. Although we probably did not cover them all in our search, these works do not present an IEC and communication system comparable to the IEC-designed system for this ITS prototype. This list of works is presented in

Table 6. Comparison of the literature survey and this work.

Reference	ITS Type	Machine Learning	Implementation	Edge Architecture	Communication System
[17]	Traffic monitoring	√	Outdoor	×	×
[19]	Traffic management	√	Laboratory	Edge AI	×
[20]	Traffic Monitoring	×	Laboratory	×	×
[21]	Vehicle tracking	√	Outdoor	×	×
[29]	Vehicle-counting performance	√	Outdoor	Edge AI	×
[30]	Dynamic traffic signal system	√	Laboratory	Edge Computing	√
[35]	Intelligent traffic monitoring system	×	Laboratory	Fog and cloud computing	×
[36]	Traffic signal controller	√	Partial SUMO	Smart edge computing	×
[38]	Smart traffic light controller	√	×	Fog computing	×
[39]	Traffic light management	×	×	Edge computing	×
This work	Vehicle detection	√	Real-urban environment	IEC	√

.

5. Conclusions

The architecture proposed in a real-urban environment demonstrated that IEC implemented intelligence in individual hardware systems to process data closer to its source, connect them to the network, and send only the necessary data, thereby reducing communication latency with 802.15.4 and enabling smarter and more flexible data handling. By establishing the link from 802.15.4 to the 900 MHz band without a cloud connection, the high latency and network congestion caused by the physical distance to cloud servers and the time to access them, among other factors, affect the immediate response of applications sensitive to time. IEC assures that this does not occur in systems requiring limited resources and can be considered an emerging infrastructure for intelligent transportation. Regarding the requirements for the ITS application, a distance of 600 m was sufficient to validate and evaluate the proposed architecture for the streets of the City of Puebla, enabling an alert signal with a transmission mean transmission latency of approximately 15.45 ms and a total end-to-end latency of 47.9087 ms.

The proposed architecture represents a practical and scalable implementation for traffic management applications, such as vehicle prioritization and traffic light coordination at intersections. While the IEC architecture reduces network latency, resources are limited. However, by defining the roles of Edge and Fog nodes within the IEC, sequential execution problems are avoided, and real-time response is improved with greater stability. This is because processing is delegated by placing the Edge node near the data collection point and performing control and storage logic in the Fog node.

Future research could contribute to addressing traffic congestion, focusing on the transportation and communications sectors, by studying the high levels of pollution resulting from increased fuel consumption. ITS (Intelligent Transportation Systems) can solve problems in urban areas by improving transportation networks through faster infrastructure response, without relying on the cloud. Therefore, using AI for decision-making at the network edge is an ideal option for real-time applications.