A Multi-Tier Vehicular Edge–Fog Framework for Real-Time Traffic Management in Smart Cities

Abstract

The factors restricting the large-scale deployment of smart vehicular networks include application service placement/migration, mobility management, network congestion, and latency. Current vehicular networks are striving to optimize network performance through decentralized framework deployments. Specifically, the urban-level execution of current network deployments often fails to achieve the quality of service required by smart cities. To address these issues, we have proposed a vehicular edge–fog computing (VEFC)-enabled adaptive area-based traffic management (AABTM) architecture. Our design divides the urban area into multiple microzones for distributed control. These microzones are equipped with roadside units for real-time collection of vehicular information. We also propose (1) a vehicle mobility management (VMM) scheme to facilitate seamless service migration during vehicular movement; (2) a dynamic vehicular clustering (DVC) approach for the dynamic clustering of distributed network nodes to enhance service delivery; and (3) a dynamic microservice assignment (DMA) algorithm to ensure efficient resource-aware microservice placement/migration. We have evaluated the proposed schemes on different scales. The proposed schemes provide a significant improvement in vital network parameters. AABTM achieves reductions of 86.4% in latency, 53.3% in network consumption, 6.2% in energy usage, and 48.3% in execution cost, while DMA-clustering reduces network consumption by 59.2%, energy usage by 5%, and execution cost by 38.4% compared to traditional cloud-based urban traffic management frameworks. This research highlights the potential of utilizing distributed frameworks for real-time traffic management in next-generation smart vehicular networks.

1. Introduction

With the rapid pace of urbanization and the continuous growth in vehicle ownership, traffic congestion and road accidents have become critical challenges in the development of smart cities [1,2]. These issues limit the smooth flow of traffic and lead to significant consequences, including longer travel times, increased driver stress, higher fuel consumption, and elevated emissions. Moreover, the inefficient traffic framework poses serious threats during emergencies, where delays can have life-threatening impacts [3]. For these reasons, the deployment of intelligent transportation systems (ITS) is an essential requirement to ensure safe, flexible, and sustainable urban mobility [4].

In earlier studies, several cloud-based ITS frameworks were proposed to address traffic management [5]. However, centralized cloud architectures face inherent challenges: (1) high latency, as large volumes of real-time traffic data must be transmitted over wide-area networks; (2) limited support for mobility, since vehicles are highly dynamic, and traditional clouds struggle to serve moving terminals efficiently; and (3) low scalability, as heterogeneous vehicular infrastructures such as vehicular ad hoc networks (VANETs), mobile nodes, and road side units (RSUs) are difficult to manage in a purely centralized system [6,7].

To overcome these challenges, researchers have introduced decentralized frameworks based on fog and edge computing paradigms [8]. A fog-enabled architecture shifts computing and storage functions from the centralized cloud to the network edge [9]. Although fog computing has less capacity than cloud computing, it significantly reduces the latency by processing data closer to vehicles [10]. The internet of vehicles (IoV) enables real-time communication between vehicles and roadside infrastructure through vehicle-to-infrastructure (V2I) links. The RSUs act as communication hubs, providing traffic information, supporting vehicle-to-vehicle (V2V) communication, and connecting vehicles with fog and cloud resources [11]. In vehicular edge–fog computing (VEFC) networks, vehicles equipped with on-board units (OBUs) function as mobile edge devices, while fog servers deployed as RSUs are responsible for collecting, processing, and storing real-time traffic information [12]. This distributed architecture improves the interaction efficiency via V2V and vehicle-to-RSU (V2R) communication, thereby enhancing the responsiveness and effectiveness of ITS [13].

There exist two categories of congestion control: (1) predictive and (2) reactive. Predictive schemes use historical or real-time traffic data to forecast congestion. The reactive ones respond after congestion occurs. Qi et al. [14] proposed an accident message attenuation model to reduce congestion caused by accidents and later designed a two-level intersection control strategy using additional warning lights [15]. The reactive solutions are effective for handling traffic issues at a local scale, but they are not valuable for implementing across the entire urban network.

Despite notable progress in ITS, existing frameworks largely rely on centralized processing, which limits the scalability and responsiveness in dynamic vehicular environments. In addition, the existing distributed frameworks face several challenges, including limited scalability, unstable service migration, a lack of coordinated area-based control, and weak microservice orchestration across heterogeneous nodes. These limitations restrict real-time implementation across large-scale deployments, motivating the design of an adaptive area-based approach. Therefore, for the efficient implementation of vehicular management, we proposed a grid-based management approach that divides the urban area into manageable regions. These regions are coordinated through a four-tier architecture, enabling localized reactive control while ensuring overall system integration, as shown in Figure 1.

In this paper, we propose an adaptive area-based traffic management architecture that ensures efficient vehicular management. Key contributions are summarized as follows:

• In Section 3.1, we present a decentralized vehicle management framework that segments an urban region into multiple operational areas, each managed by the respective proxy servers via RSUs.
• In Section 3.2, we employed a microservice-based application approach for implementing the proposed distributed framework. The proposed application design enables dynamic placement and scaling [16] of application modules across multiple network nodes. Moreover, this approach enables the integration of various modular strategies in the system.
• In Section 4.2, a mobility management algorithm is presented for the provision of the efficient migration of services while considering the position and speed of the vehicle, along with the availability of RSUs. Correspondingly, the selection of intermediate nodes to facilitate service migration in the absence of RSUs is also considered.
• In Section 4.3, a dynamic vehicular clustering algorithm is presented that groups the RSUs based on proximity, communication range, and latency, to ensure efficient, low-latency, and reliable V2I communication.
• In Section 4.4, a dynamic microservice assignment algorithm is presented that effectively places microservices according to the location and resource availability.
• In Section 6, we evaluate the effectiveness of our proposed schemes on multiple scales on the EUA dataset. Our evaluation demonstrates enhanced performance with significant improvements in latency, network consumption, execution cost, and energy efficiency, as compared to existing schemes.

The paper is structured as follows. Section 2 provides the literature related to advanced traffic management schemes. Section 3 proposes a novel adaptive area-based vehicular management framework. Section 4 presents the schemes designed for the effective management of the vehicular network. Section 5 defines the simulation setup organized for evaluation of the proposed schemes. Section 6 presents the results of the multiscale evaluations performed using the proposed approaches. Finally, Section 7 concludes the paper and outlines future research directions.

2. Related Work

Several recent studies have proposed decentralized frameworks incorporating fog/edge computing architectures for the effective implementation of vehicular networks. The centralized platforms often hinder the real-time processing of vehicular information due to their cloud-centric resource provision. The authors of [17] implemented a fog-enabled decentralized framework that provides resources in a decentralized manner. The framework provides a significant reduction in delay, as compared to cloud-based platforms. They deployed a cloud platform for storing traffic information. The deployed platform is favorable in providing low-latency smart traffic solutions. Its large-scale deployment faces challenges like scalability, resource management, and privacy [18], due to the dependence on resource-constrained fog nodes.

In [19], a fog computing-based multi-agent management approach is adopted for implementing a traffic management system. The system effectively provides traffic light adjustment through Q-learning-based processing of real-time information. It also provides dynamic adaptations that respond to varying traffic volumes, offering significant improvements compared to traditional traffic control systems. Additionally, the study proposes a security protocol to maintain data integrity during vehicle-to-traffic light communication, thereby addressing flaws in conventional systems. However, although the proposed system represents progress in smart city traffic management, its design lacks area-based control, which makes its large-scale implementation face control challenges.

In recent research, edge computing has made a major contribution to the field of intelligent traffic management systems (ITMS) and especially in predicting traffic congestion. In [20], a congestion prediction system is proposed that combines the use of fuzzy logic with hybrid approaches to predict and control congestion in real time. The solution takes advantage of edge computing to perform local processing, therefore, decreasing the latency and providing faster decision-making processes. However, the large-scale implementation is restricted, due to the high traffic data that has to pass through several hops before accessing the cloud architecture. The reliance on expert guidance for configuring the fuzzy logic system also creates constraints in terms of flexibility and the ease of large-scale implementation. In spite of these limitations, the suggested scheme outperforms traditional centralized schemes in terms of delay and accuracy.

The authors in [21] proposed a novel fog-enabled traffic light management strategy (TLMS), which reduces vehicle waiting times at intersections and improves traffic flow. Through fog resources, this strategy facilitates the real-time processing of information collected through the V2I links. The system achieves a 45% reduction in delay. The dependency on cloud and fog nodes limits the large-scale implementation of the framework, and the lack of microservice management limits the scalable implementation. This work is a significant contribution towards the efficient deployment of traffic management, illustrating the effectiveness of a distributed architecture for real-time vehicle management.

The recent studies have shown the importance of adaptive microservice management schemes for the implementation of efficient VANETs. Conventional clustering algorithms are unable to tackle issues related to the dynamic nature of vehicular networks. For advanced vehicular networks, a robust software-defined vehicular fog computing (SDFC) framework is presented in [13] that effectively manages the network through adaptive cluster formation and resource utilization. The proposed framework also incorporates a load-balancing scheme to manage traffic-based load assignment. The scheme has limitations related to large-scale implementation, controller placement, and disruptions from mobile network handovers.

A multi-layered traffic scheme for a situation-aware vehicular management framework is presented in [22] that enables real-time information processing through the utilization of fog/cloud resources. The system predicts traffic-related situations through logistic regression and artificial neural networks. The proposed framework enhances adaptive traffic signal control and optimizes vehicle routing. The high cost hinders the large-scale implementation of this framework. A hybrid fog/edge-enabled approach for task-aware processing is presented in [23]. This approach provides reduced latency and improved network utilization through dynamic clustering and load balancing.

A fog-enabled smart navigation system of emergency vehicles (SNSEV) for real-time data analysis and processing is presented in [24]. SNSEV enhances the response time by dynamically adjusting traffic lights and giving emergency vehicles priority routes, causing a significant improvement in the safety and welfare of people in cities. The approach also has various benefits, such as making decisions in real time, managing dynamic traffic flow, and prioritization. The recent smart traffic management frameworks are summarized in

Table 1. Summary of recent intelligent traffic management frameworks.

Ref.	Methodology	Limitations	Implementation	Technologies	Achievements
[17] 2020	Fog–cloud IoT framework for real-time monitoring, congestion detection, and traffic light management.	Limited fog capacity, scalability issues, and reliance on IoT sensors.	Real-time monitoring system with congestion detection, adaptive traffic lights, and Twitter-based alerts.	IoT, Fog, Cloud, ThingSpeak, Twitter API, Ultrasonic Sensors.	Faster response, higher bandwidth efficiency, and real-time alerts.
[19] 2021	Multi-agent traffic light control on fog nodes using Q-learning for adaptive signal timing.	Multi-intersection coordination challenges, dependence on fog nodes, and limited scalability.	An adaptive traffic light system adjusts green time and secures vehicle data.	Fog, Q-learning, IoT, Security Protocols.	Improved regulation efficiency, reduced delays, and enhanced security.
[20] 2022	Edge computing-based congestion prediction using fuzzy inference and hybrid OWNB.	Scalability concerns, longer training time, and reliance on expert guidance.	Real-time congestion prediction and direction detection for faster decisions.	Edge, IoT, Fuzzy Logic, Hybrid OWNB.	High accuracy and precision and fast decision-making.
[21] 2022	Fog-based traffic light management with fuzzy inference and V2I communication.	Needs strong fog–cloud infra, privacy concerns, and no emergency vehicle prioritization.	Real-time signal management optimizes waiting time and traffic flow.	Fog, Fuzzy Logic, V2I, GPS.	45% less vehicle delay, 35% shorter total delay, 30% higher throughput, and 8% fuel savings.
[13] 2024	Software-defined fog computing (SDFC) framework with clustering, load balancing, and intelligent controller placement in VANETs.	Frequent handovers, scalability, controller placement, and dynamic network conditions.	Resource-optimized vehicular network with better data flow and latency control.	Fog, SDN, CRAN, Dynamic Clustering.	28% faster response, 23% lower latency, and 25% faster convergence.
[22] 2024	Four-layer fog–cloud–IoT architecture using machine learning (ANN, Logistic Regression) for traffic prediction, adaptive timing, and routing.	Scalability issues, infra dependency, sensor accuracy, and high computational cost.	Situation-aware traffic management with adaptive signals and re-routing.	IoT, Fog, Cloud, ANN, Logistic Regression, GPS.	Adaptive phase planning, real-time routing, better load balancing, and improved safety.
[23] 2024	Hybrid IoT–Fog–Cloud architecture with dynamic load balancing and resource allocation.	Simulation-based validation, unstable networks, scalability challenges, and privacy concerns.	A hybrid system distributing processing tasks across IoT, fog, and cloud.	IoT, Fog, Cloud, Machine Learning.	20–30% lower latency, 25% better resource use, 15% improved decision-making, and stronger privacy.
[24] 2025	Fog–cloud-based navigation for emergency vehicles using IoT data for real-time routing and traffic signal adjustments.	Infra dependency, privacy risks, frequent updates, and scalability issues.	Smart EV navigation ensures priority routes and dynamic signal control.	Fog, Cloud, IoT, Priority Control.	Faster emergency response, improved safety, and efficient traffic management.

.

Most of the existing work on ITS is focused on localized vehicle management [25], congestion control [26], and real-time monitoring [27]. These schemes achieved reduced latency and improved throughput, but they lack adaptive area-based management. Most of the frameworks designed so far are monolithic in nature, restricting their large-scale deployment. The mobile nature of vehicular networks requires a seamless migration of tasks and heterogeneous infrastructures for effective resource management. Effective balancing of loads among multiple network nodes requires the dynamic clustering of devices for efficient vehicular network deployment. In addition, recent proposed frameworks lack integration of real-world datasets in their evaluations, restricting their applicability in dynamic urban environments. To address these issues, we have proposed an adaptive area-based segmentation of the urban traffic network for better information processing. In addition, we have proposed multiple schemes to effectively manage mobility, clustering, and service migration to efficiently manage vehicular traffic. Our proposed schemes are evaluated on multiple scales with different vehicular loads to ensure reliable and scalable deployments.

Table 2. Comparison with existing surveys in autonomous driving and vehicular AI systems.

Ref.	Year	Area-Based Segmentation	Service Migration	Clustering Strategy	Microservice Orchestration	Architecture	Real Dataset Integration	Scale of Evaluation
[17]	2020	×	Not supported	None	Monolithic IoT services	Cloud + Fog	×	Small-scale IoT sensors
[19]	2021	×	Not supported	None	Monolithic traffic-light logic	Fog-only	×	Single/multi-intersection
[20]	2022	×	Not supported	None	Rule-based components	Edge + IoT	×	Local congestion points
[21]	2022	×	Not supported	None	Centralized fuzzy systems	Fog + V2I	×	Intersection-level
[13]	2024	×	Only SDN-based handover	Latency-driven RSU/VANET clustering	SDN functions, not microservices	Fog + SDN	×	Moderate-scale VANET
[22]	2024	×	Not supported	Latency-aware resource grouping	ML modules, not microservices	Fog-Cloud-IoT	×	Multi-intersection
[23]	2024	×	Occasional reallocation	Local-based resource grouping	Semi-moduler	Fog-Cloud-IoT	×	Medium-scale simulation
[24]	2025	×	Not supported	None	Monolithic navigation logic	Fog + Cloud	×	Emergency vehicle routing
Proposed	2025	✓ (microzones)	ContinuousRSU proxy → RSU migration via VMM	Dynamic latency + range-based vehicular clustering	Fully microservice-based orchestration with DMA	Cloud + Proxy + Fog (multi-tier VEFC)	✓	Large-scale (118 RSUs, multi microzones, 10–60 vehicles)

presents the limitations of the previous studies, summarizes their key features, and describes the novelty of the proposed architecture.

Existing studies provide valuable insights into fog/edge-enabled traffic management; however, they generally lack area-based control, do not support seamless microservice migration, and provide limited scalability due to static clustering or centralized decision-making. Moreover, most frameworks rely on simulated or synthetic datasets, limiting their real-world applicability. These gaps motivate our adaptive area-based architecture, which integrates mobility-aware service migration, dynamic clustering, and distributed microservice orchestration to overcome these limitations.

3. System Architecture

The urban traffic management approach has to deal with city-wide vehicular traffic control. To achieve efficient management, the large urban area is partitioned into multiple areas, each controlled by a dedicated control unit. The proposed VEFC-enabled area-based traffic management scheme is explained in this section.

3.1. Adaptive Area-Based Traffic Management Framework

In this section, we present an area-based traffic management framework that leverages the VEFC paradigm within the Internet of Vehicles. The proposed framework divides the urban region into multiple microzones and assigns a proxy server to each microzone. Multiple fog nodes assigned to each microzone act as RSUs, processing real-time roadside information collected from vehicles and infrastructure. The cloud server resides at the uppermost tier of the hierarchy, providing centralized coordination and control. The smart vehicles moving across these regions are mobile edge nodes with OBUs enabling V2V and V2I communication. Figure 2 illustrates microzones with RSUs denoted in red, proxy servers in blue, and vehicular movement in the Melbourne Central Business District. For each vehicle in the scenario, different datasets are generated for each vehicle to generate mobility positions in their desired microzone. The proposed approach is based on four layers as described below:

• Cloud Layer: This is the uppermost layer of the proposed architecture, containing the cloud server, the most resourceful entity of the architecture. The cloud server is responsible for the processing of the tasks requiring resources not available at the lower layers. The cloud server stores historical traffic information for predictive analysis to forecast congestion. All the microzones are connected to this layer for the overall management of the urban area.
• Proxy layer: This layer consists of multiple proxy servers, with each proxy server acting as a supervisory head to each microzone. The purpose of the proxy server is to manage traffic within its designated microzone. For effective vehicular management and the seamless exchange of traffic information, all proxy servers are interconnected with each other. Moreover, all proxy servers are connected to the centralized cloud server for the execution of tasks requiring extra resources.
• RSU Layer: This layer comprises fog nodes acting as RSUs in the proposed framework. These RSUs are responsible for the collection and processing of vehicular information. For real-time traffic management, multiple RSUs are assigned to each microzone. All the RSUs are associated with the proxy server of the microzone. Similarly, they are also interconnected and are utilized for the calculation of the shortest path between multiple network components.
• Traffic Layer: This layer consists of all the traffic monitoring equipment and vehicles. The vehicles in the network are equipped with OBUs and act as a mobile edge computing (MEC) node. The nodes present in this layer are utilized for the transmission and reception of real-time vehicular information for efficient traffic management. Additionally, it executes the commands received from fog and proxy servers to manage the traffic flow.

In each microzone, there exist multiple RSUs for the collection of vehicular information. These RSUs communicate with vehicles and traffic control units for real-time traffic control. Each microzone is assigned to a proxy server. The proxy server is responsible for cooperating with the RSUs residing in the microzone for the collection and processing of vehicular information. All proxy servers are interconnected to share information for efficient traffic management. The cloud server at the top of the hierarchical structure is responsible for the collection of information from proxy servers. The cloud resources are utilized for global traffic analysis and decision support. This hierarchical design enhances microscopic models at the RSU level with macroscopic integration through proxy and cloud coordination, thereby improving scalability, reducing latency, and enabling adaptive traffic control across the entire urban network.

The RSUs within each management area collect detailed vehicular information from OBUs on individual roads and lanes. In the proposed framework, we divide the urban area into several microzones. We completely utilize the benefits of distributed computing. We have adopted a modular application approach, consisting of several microservices. The details of the application model are described in the next section.

3.2. Application Model

The directed acyclic graph (DAG) of the deployed application is shown in Figure 3. The DAG contains multiple vertices that represent microservices, and edges denote the data dependencies between these modules. The proposed framework consists of five key microservices that are specified below:

• Storage Microservice: This module is responsible for storing the information requiring long-term usage. In smart traffic control environments, the critical traffic information, e.g., historical traffic data, accidents, etc., is needed for predictive traffic schemes and forensic analysis.
• Microzone Traffic Microservice: This microservice is initially placed at proxy servers to process the traffic information of the assigned area. This module requires more processing resources, as it applies advanced artificial intelligence techniques on the acquired information for real-time traffic management. Moreover, the proxy servers not only have to process the allocated microzone information but also have to coordinate with other areas for efficient traffic management. This microservice is also responsible for the transmission of signals to the Emergency Control Module as per requirements.
• Data Collection Microservice: This module is initially assigned to the fog nodes working as RSUs. This microservice preprocesses the real-time traffic information gathered from the smart vehicles. These modules preprocess that information and forward the outcomes to the Microzone Traffic Microservice and Vehicle Microservice.
• Vehicle Microservice: This microservice is placed on the smart vehicles as an OBU to collect and exchange real-time vehicular and traffic information with nearby vehicles (i.e., V2V) and roadside infrastructure (i.e., V2I). This module interacts with the Data Collection Microservice at the RSUs to ensure the real-time exchange of safety messages, congestion information, and emergency alerts.
• Emergency Control Microservice: This microservice is placed on different actuators to display information about traffic incidents or accidents, identifying traffic disruptions such as accidents or road closures.

All microservices are responsible for the complete execution of the deployed application. They coordinate with each other to provide effective vehicular management. These latency-sensitive modules are to be deployed on distributed nodes to avoid delayed responses. Only the storage module, requiring high resources, is to be placed on the cloud server.

4. Methodology

This work adopts a multi-tier VEFC architecture (Section 3) and a modular application model to support mobility-aware latency-sensitive traffic management. Our methodology first defines the system entities and the mathematical model, after which three schemes are executed across different network nodes. Together, these schemes operate as a unified workflow that maintains low-latency operation under dynamic vehicular conditions. The evaluation logic follows two scenarios using the EUA dataset and the iFogSim2 platform, enabling the multi-scale validation of scalability, resource use, and microservice orchestration efficiency.

4.1. Mathematical Model

This section defines the mathematical model for the architecture, on which we have executed the proposed algorithms for the efficient deployment of the vehicular network. Our model contains a set of smart vehicles, RSUs, proxy servers, and a cloud server, as described in the previous section. Equation (1) defines the position of a vehicle $car$ at time t, and the instantaneous speed of the vehicle is defined by Equation (2).

$${\mathrm{Location}}_{\mathrm{car}}\left(t\right)=(x_i\left(t\right),y_i\left(t\right))$$

(1)

$${\mathrm{Speed}}_{\mathrm{car}}\left(t\right)=v_i\left(t\right)$$

(2)

The RSUs are at a fixed location in the architecture. Each RSU f has a fixed position $(x_f,y_f)$. The Euclidean distance between vehicle i and RSU f is defined by Equation (3), which is implicitly used in different functions of the proposed algorithms.

$$d_{i,f}\left(t\right)=\sqrt{{\left(x_i\left(t\right)-x_f\right)}^2+{\left(y_i\left(t\right)-y_f\right)}^2}$$

(3)

The internal functions used in the pseudo-code are modeled as follows:

• $Rcoverage\left(\right)$ returns the coverage radius of an RSU f, denoted as $R_{coverage}\left(f\right)$.
• $Rcommunication\left(\right)$ returns the communication range of RSU f, denoted as $R_{comm}\left(f\right)$.
• $load\_RSU\left(f\right)$ returns the current load $L_f\left(t\right)$ (e.g., number of active services/sessions).
• $RSUload\left(f\right)$ returns the maximum admissible load $L_f^{max}$.
• $checkLatency(vehicle,f^{\prime })$ returns the latency $l(i,f^{\prime })$ between vehicle i and RSU $f^{\prime }$.
• $resources\_avail\left(f\right)$ returns the remaining resource vectors $R_f^{avail}\left(t\right)$ = $(CP{U}_f^{avail},RA{M}_f^{avail},B{W}_f^{avail})$.

4.1.1. Mobility Management Conditions

The proposed mobility management algorithm decides whether to keep a service at the current RSU $RS{U}_{current}\left(\right)$, migrate it to the nearest RSU $RS{U}_{nearest\left(\right)}$, or migrate it to a proxy, based on the coverage and load constraints, as defined by Equations (4) and (5).

$$d_{i,f}\left(t\right)\le R_{\mathrm{coverage}}\left(f\right)$$

(4)

$$L_f\left(t\right)\le L_f^{max}$$

(5)

In Algorithm 1, the conditions at Steps 10–15 implement the following logic: if the nearest RSU satisfies (4) and (5), the call $migrateServiceToRSU(car,RSUnearest)$ is triggered; otherwise, if (5) is violated for the nearest RSU, the service is migrated to a proxy server ($migrateServiceToProxy\left(car\right)$), having more resources for service execution. These rules minimize the service disruption by keeping the vehicle inside coverage while avoiding overloaded RSUs.

Algorithm 1 Vehicle mobility management

1: procedure ManageCarMobility($car,t$) 2:         $Locatio{n}_{car}\left(\right)$← $(x_i,y_i)$                                 ▹ Get current position of the vehicle $(x,y)$ 3:         $Spee{d}_{car}\left(\right)$← $v_i\left(t\right)$                                           ▹ Get current speed of the vehicle $(m/s)$ 4:         $RS{U}_{nearest}\left(\right)$← $findNearestRSU\left(Locatio{n}_{car}\left(\right)\right)$           ▹ Find nearest RSU to its position 5:         $RS{U}_{current}\left(\right)$← $car.getAssignedRSU\left(Locatio{n}_{car}\left(\right)\right)$               ▹ Get current RSU assigned 6:         $RS{U}_{coverage\_area}\left(\right)$← $R_{coverage}\left(\right)$                                       ▹ RSU’s coverage area in meters 7:         $RS{U}_{range}\left(\right)$← $R_{communication}\left(\right)$                          ▹ RSU’s communication range in meters 8:         $RS{U}_{current\_load}\left(\right)$← $load\_RSU\left(RS{U}_{current}\left(\right)\right)$         ▹ Current load on the assigned RSU 9:         $Ma{x}_{load}\left(\right)$← $RS{U}_{load}\left(RS{U}_{current}\left(\right)\right)$                     ▹ Maximum load capacity of the RSU 10:     if $RS{U}_{nearest}\left(\right)$≠ $RS{U}_{current}\left(\right)$ AND $RS{U}_{current\_load}\left(\right)$< $Ma{x}_{load}\left(\right)$ then 11:           $migrateServiceToRSU(car,RS{U}_{nearest})$       ▹ Migrate car’s service to the nearest RSU 12:           $updateCarAssignedRSU(car,RS{U}_{nearest})$                    ▹ Update the car’s assigned RSU 13:     else if $RS{U}_{nearest}\left(\right)$≠ $RS{U}_{current}\left(\right)$ AND $RS{U}_{current\_load}\left(\right)$= $Ma{x}_{load}\left(\right)$ then 14:           $migrateServiceToProxy\left(car\right)$                ▹ If the RSU is full, migrate to a proxy server 15:           $updateCarAssignedProxy\left(car\right)$                               ▹ Update the car’s assigned proxy 16:     else if $RS{U}_{nearest}\left(\right)$= $RS{U}_{current}\left(\right)$ then 17:           $continueServiceAtRSU\left(car\right)$                       ▹ Continue the service at the current RSU 18:     end if 19: end procedure

4.1.2. Clustering Conditions

The proposed clustering algorithm groups RSUs into dynamic clusters around a vehicle to ensure feasible and low-latency V2I connectivity. For vehicle i, the internal variables in Algorithm 2 correspond to

• $V_{location}$ ← $Locatio{n}_{car}\left(t\right)$ = $(x_i\left(t\right),y_i\left(t\right)),$
• $V_{range}\left(\right)$ ← the maximum admissible communication distance $V_{range}\left(i\right),$
• ${\sigma }_i$ ← the latency threshold.

RSU $f^{\prime }$ becomes a cluster member of vehicle i if it is within communication range and satisfies a latency bound, as given in Equation (6).

$$d_{i,f^{\prime }}\left(t\right)\le V_{\mathrm{range}}\left(i\right),\mathcal{l}(i,f^{\prime })\le {\sigma }_i$$

(6)

The internal function $calculateInRange(f_{lat}^{\prime },f_{long}^{\prime },V_{range}\left(\right))$ in Steps 12–16 of Algorithm 2 evaluates the first inequality in (6), while $checkLatency(vehicle,f^{\prime })$ computes $l(i,f^{\prime })$. The pruning step (Steps 20–28) removes RSUs that violate $l(i,f^{\prime })$ ≤ ${\sigma }_i$. Hence, DVC realizes a latency- and range-constrained clustering around the vehicle.

Algorithm 2 Dynamic vehicular clustering (DVC) algorithm

1: procedure ManageClustering($vehicle$, t, $loc$, $lf$) 2:     $V_{location}$ ← $(x_i,y_i)$             ▹ Get location info of the vehicle 3:     $RS{U}_{assigned}\left(\right)$ ← $vehicle.getAssignedRSU\left(\right)$  ▹ Get the assigned RSU for the vehicle 4:     $RS{U}_{neighbors}\left(\right)$ ← $RS{U}_{assigned}\left(\right).getetNeighboringRSUs\left(\right)$ ▹ Get all neighbour RSUs 5:     $V_{range}\left(\right)$ ← $vehicle.getCommunicationRange\left(\right)$  ▹  Get the communication range 6:     $V_{comm}\left(\right)$ ← $vehicle.getLatencyThreshold\left(\right)$      ▹ Get the latency threshold 7:     $RS{U}_{cluster}\left(\right)$ ← $null$       ▹ Initialize the list of cluster members (RSUs) 8:     $RS{U}_{cluster}\left(\right).mapToLatency$ ← $\left\{\right\}$    ▹ Initialize the map of RSUs to latency 9:     $V_{lat}\left(\right)$ ← $V_{location}\left(\right).get\left(lat\right)$          ▹ Get the latitude of the vehicle 10:   $V_{long}\left(\right)$ ← $V_{location}\left(\right).get\left(long\right)$         ▹ Get the longitude of the vehicle 11:   for condition do 12:         $f_{lat}^{\prime }$ ← $f^{\prime }.get\left(lat\right)$       ▹ Get the latitude of the neighboring RSU f’ 13:         $f_{long}^{\prime }$ ← $f^{\prime }.get\left(long\right)$     ▹ Get the longitude of the neighboring RSU f’ 14:         $flag$ ← $calculateInRange(f_{lat}^{\prime },f_{long}^{\prime },V_{range}\left(\right))$ ▹ Check if RSU f’ is within range 15:         if $flag$ then 16:              $lis{t}_{cm,f}.add\left(f^{\prime }\right)$      ▹ Add RSU f’ to the list of cluster members 17:              $latency$ ← $checkLatency(vehicle,f^{\prime })$  ▹ Calculate vehicle and RSU latency 18:              $mapCMToLatency.put(f_{long}^{\prime })$ ← $latency$▹ Store latency in mapCMToLatency 19:         end if 20:         if $Latency\_Filtering\_Enabled\left(\right)$ then     ▹ If latency filtering is enabled 21:              $temp$ ← $list$                 ▹ Create a temporary list 22:              for $f^{\prime }$ in $lis{t}_{cm,f}$ do do       ▹ Iterate over all cluster members 23:                  if $mapCMToLatency.get(f^{\prime },vehicle)$ > $\sigma$ then▹ Check if latency exceeds 24:                       $temp.remove\left(f^{\prime }\right)$        ▹ Remove f’ if latency is too high 25:                       $mapCMToLatency.remove\left(f^{\prime }\right)$   ▹ Remove latency mapping for f’ 26:                  end if 27:              end for 28:              $lis{t}_{cm,f}\leftarrow temp$     ▹ Update list of cluster members after pruning 29:         end if 30:     end for 31:     $returnlis{t}_{cm,f},mapCMToLatency$▹ Return final list (latencies) of cluster members 32: end procedure

4.1.3. Microservice Placement Constraints

Equation (7) defines the demand vector of each microservice m in the microservice placement algorithm. F is a set of hierarchical network nodes (fog, proxy, cloud) extracted from the application DAG. The ordered list of application microservices that must be placed (Vehicle, Data Collection, Microzone Traffic, Emergency Control, Storage) is defined by a.

$$R_m=\left({\mathrm{CPU}}_m,{\mathrm{RAM}}_m,{\mathrm{BW}}_m\right)$$

(7)

Each candidate node f (RSU, proxy, or cloud) exposes an available vector $R_f^{avail}\left(t\right)$. The internal function $resources\_avail(f,m)$ is satisfied if and only if the resource-feasibility inequalities defined in Equation (8) are satisfied.

$${\mathrm{CPU}}_f^{\mathrm{avail}}\left(t\right)\ge {\mathrm{CPU}}_m,{\mathrm{RAM}}_f^{\mathrm{avail}}\left(t\right)\ge {\mathrm{RAM}}_m,{\mathrm{BW}}_f^{\mathrm{avail}}\left(t\right)\ge {\mathrm{BW}}_m$$

(8)

Step 11–17 and 24–28 of Algorithm 3 use (8) to decide whether to place a module or to search the cluster members $f^{\prime }.getCMs\left(\right)$ for an eligible node. When a microservice cannot be placed along the direct leaf-to-root path P, DMA explores nearby cluster members and then higher-tier nodes, always respecting (8). This realizes a distributed resource-constrained placement and migration policy.

Algorithm 3 Dynamic microservice assignment (DMA) algorithm

1: procedure ManageMicroservicePlacement(F, a) 2:     $mapNodeTo\mu Inst$ ← $\left\{\right\}$       ▹ Initialize the microservice to node mapping 3:     $mapNodeTo\mu Inst$ ← $\left\{\right\}$        ▹ Initialize the service discovery information 4:     $m_{placed}$ ← $\left\{\right\}$              ▹ Initialize the placed microservice list 5:     P ← $getLeafToRootPaths\left(F\right)$            ▹ Get the paths from leaf to root 6:     $mapPtoNextNode$ ← $getNextNode\left(P\right)$    ▹ Get the next eligible node for each path 7:     m ← $getNextMicroservice(a,m_{placed})$     ▹ Get next eligible microservice to place 8:     while m is not $null$ do    ▹ While microservices are available for placement 9:         for $p:=P$ do                   ▹ Iterate over each path 10:            f ← $mapPtoNextNode.get\left(p\right)$        ▹ Get the next node for the path p 11:            if $resources\_avail\left(f\right)$ then    ▹ Check if resources are available on node f 12:                $placeModule(f,m)$           ▹ Place the microservice on node f 13:                $mapNodeTo\mu Inst.get\left(f\right).add\left(m\right)$     ▹ Update microservice, node mapping 14:                $f.updateResourcesAvail\left(\right)$     ▹ Update the available resources on node f 15:            else 16:                $notPlacedPaths.add\left(p\right)$         ▹ Add paths where placement failed 17:            end if 18:        end for 19:        for $p:=notPlacedPaths$ do       ▹ Reattempt placement for unplaced paths 20:            f ← $mapPtoNextNode.get\left(p\right)$          ▹ Get the next node for the path p 21:            $f^{\prime }$ ← $f.getCMs\left(\right)$            ▹ Get the cluster members of node f 22:            $placed$ ← $false$ 23:            for $f^{\prime }$ do                ▹ Iterate over the cluster members 24:                if $resources\_avail(f^{\prime },m)$ then   ▹ Check if resources are available on f’ 25:                    $placeModule(f^{\prime },m)$           ▹ Place the microservice on f’ 26:                    $mapNodeTo\mu Inst.get\left(f^{\prime }\right).add\left(m\right)$▹ Update mapping, cluster member f’ 27:                    $f^{\prime }.updateResourcesAvail\left(\right)$   ▹ Update the available resources on f’ 28:                    $placed$ ← $true$ 29:                    $\mathbf{Break}$ 30:                end if 31:            end for 32:        end for 33:        while $placed$ is $false$ do    ▹ Keep retrying until placement is successful 34:            f ← $getNextInPath(p,f)$          ▹ Get the next node in the path p 35:            if condition then          ▹ Check if resources are available 36:                $placeModule(f,m)$           ▹ Place the microservice on f 37:                $mapNodeTo\mu Inst.get\left(f\right).add\left(m\right)$     ▹ Update the mapping for node f 38:                $f.updateResourcesAvail\left(\right)$        ▹ Update resources on node f 39:                $placed$ ← $true$ 40:                $mapPtoNextNode.get\left(p\right).set\left(f\right)$     ▹ Set the next node in the path 41:                $m_{placed}.add\left(m\right)$          ▹ Mark the microservice as placed 42:            end if 43:        end while 44:        m ← $getNextMicroservice(a,m_{placed})$ ▹ Get the next microservice to be placed 45:    end while 46:    $mapNodeToSD$ ← $generateSD\left(mapNodeTo\mu Inst\right)$ ▹ Generate service discovery info 47: end procedure

4.1.4. Latency and Cost-Oriented Objective

The overall design objective of the three algorithms is to reduce the end-to-end latency and network usage while keeping the execution cost moderate. Let S denote the set of active service control loops (Vehicle → Data Collection → Microzone Traffic → Emergency Control/Storage). For a given deployment (i.e., chosen RSUs, proxy, and cloud nodes for all microservices), we denote

• $T_s$: end-to-end delay of loop s$ϵ$S;
• $N_s$: network usage for loops s;
• $C_s$: execution cost for loop s.

$$\underset{\mathrm{placement},\mathrm{migration}}{min}\sum _{s\in S}\left(\alpha T_s+\beta N_s+\gamma C_s\right)$$

(9)

Equation (9) defines the simplified multi-objective cost function with weighing factors $\alpha$, $\beta$, $\gamma$ ≥ 0. The VMM, DVC, and DMA algorithms act as distributed heuristics that enforce constraints (4)–(8) while implicitly driving the system towards low values of the composite objective (9). The improvement reported in the latency, network consumption, energy usage, and execution cost compared to the centralized and edgeward baselines is therefore consistent with this formal objective.

4.2. Vehicle Mobility Management Algorithm

Vehicle movement is an important factor to be considered while designing modern vehicular management systems. Their frequent position change impacts the RSU selection procedure. The vehicle mobility management (VMM) algorithm presented in this research provides an efficient service migration, depicted in Algorithm 1. The available RSUs, along with the position and speed of the vehicles, are crucial parameters considered by the VMM scheme for smooth mobility management. The designed approach is also responsible for the smooth service migration and intermediate node selection in the absence of RSU availability. The VMM approach optimizes the network performance through effective connectivity management between the infrastructure and vehicles.

The VMM uses several variables, namely, $Locatio{n}_{car}\left(\right)$ represents the vehicle’s current location containing Cartesian coordinates (x, y); $Spee{d}_{car}\left(\right)$ represents the current speed of vehicles; $RS{U}_{nearest}\left(\right)$ represents the nearest RSU available to the vehicles; $RS{U}_{current}\left(\right)$ represents the vehicles currently connected RSU; $RS{U}_{coverag{e}_{a}rea}\left(\right)$ is the coverage area of RSU in meters; $RS{U}_{range}\left(\right)$ specifies the RSU’s communication radius; $RS{U}_{curren{t}_{l}oad}\left(\right)$ describes the present load on the assigned RSU; and $Ma{x}_{load}\left(\right)$ ensures that RSU does not exceed its capacity. The VMM monitors vehicular movement to determine whether the service migration is required. Service migration occurs whenever the nearest RSU differs from the currently assigned RSU, even if the current RSU is not fully loaded. This ensures that the vehicle always connects to the most geographically suitable RSU, maintaining optimal V2I communication and reducing handover delay. Migration to the proxy server is only triggered when the current RSU is overloaded. The algorithm inspects vehicles, controls the connectivity of RSUs, and redirects services to the proxy server in case of RSU congestion, limiting the effect on the network and energy.

4.3. Dynamic Vehicular Clustering Algorithm

For optimum network management, improved communication between network components plays an important role. In the proposed vehicular framework, the RSUs are resource-constrained devices, and their clustering presents an effective way to optimize architectural efficiency. The proposed dynamic vehicular clustering (DVC) algorithm is presented below, which groups the RSUs on the basis of their location, range, and offered latency. This clustering ensures efficient and reliable V2I communication in vehicular networks.

The algorithm is initialized by collecting information related to vehicle location, assigned RSU, neighboring RSUs, communication range of vehicle, and latency threshold (Steps 2–6). The algorithm utilizes this information for accurate clustering and location prediction. In steps 7–10, the algorithm calculates the distance between vehicles and the neighboring RSUs by using the vehicle’s Cartesian coordinates. After that, identification of appropriate RSUs that fall within the range of the vehicle and addition of these RSUs to the list of cluster members (CMs) are performed in steps 11 to 17. Moreover, the algorithm also manages CMs through the active removal of RSUs offering latency more than the threshold. Finally, the list of CMs is finalized along with their corresponding latencies to ensure an efficient RSU selection process for communication purposes. The algorithms guarantee optimum network performance through real-time V2I connectivity. In cases where RSUs are overburdened, the traffic load is transferred to proxy servers to ensure seamless and efficient vehicular management.

4.4. Dynamic Microservice Assignment Algorithm

Microservices are independent modules placed on network devices for performing specific tasks. The proposed distributed application design allows the migration of modules between various nodes. The dynamic microservice assignment (DMA) scheme utilizes the service discovery function of iFogSim2 [28] for the discovery and placement of required modules on different distributed network nodes. The MicroservicesController class manages the load balancing and microservice placement. The DMA scheme ensures the effective placement of microservices. The proposed scheme takes into account the resource availability and location of nodes during module assignment. It allocates services to nodes that have enough resources or to cluster members that are close to each other to facilitate efficient placement. Service discovery information is also updated by the algorithm, and this guarantees smooth orchestration. The DMA algorithm is given below.

To evaluate the performance of our proposed schemes, we conducted experiments using the iFogSim2 simulator, that provides built-in support for mobility, dynamic clustering, and microservice orchestration. These capabilities directly align with the schemes proposed in this work. iFogSim2 extends the original iFogSim with modular components for service migration, distributed cluster formation, and microservice management and provides realistic modeling of heterogeneous fog/edge hierarchies and dataset integration. In our study, iFogSim2 is configured conceptually to mirror the VEFC architecture: vehicles operate as mobile edge entities, RSUs map to fog gateways, proxy servers represent tier-1 network nodes, and microservice modules are deployed according to the proposed mobility scheme. The simulator’s mobility models (directional and random) and clustering engine are enabled to support the proposed schemes. The EUA dataset–based spatial configurations are imported through the ’DataParser’ module, allowing us to evaluate the proposed framework under realistic mobility, resource heterogeneity, and service-migration conditions.

5. Simulation Setup

The independent and scalable nature of the microservices is the key characteristic to adopt the modular approach for decentralized applications. To horizontally scale among multiple microservice instances, load balancing and scheduling policies can benefit from the dynamic clustering of the edge/fog nodes [29]. All the evaluations are performed by incorporating the EUA dataset [30]. In our evaluations, we have implemented two different scenarios. The first scenario compared the proposed adaptive area-based traffic management (AABTM) framework with the traditional centralized framework. In the second scenario, we have evaluated our proposed DMA-clustering approach with the Edgeward placement approach defined below:

• Edgeward: this placement technique only considers the vertical scalability of application modules without taking fog node clustering and horizontal scalability-based load balancing into consideration [31].
• DMA-clustering: this approach makes use of both the dynamic vehicular clustering (DVC) algorithm [32] and the dynamic microservice assignment (DMA) scheme.

The EUA dataset contains real-world spatial information for communication infrastructure in major Australian cities, including RSU coordinates, elevation profiles, and physical separation between nodes. These values directly reflect realistic deployment constraints used by the Australian Communications and Media Authority. Vehicular positions in our simulations follow mobility distributions derived from the EUA spatial grid to ensure realistic road-network density and RSU coverage patterns. This strengthens the fidelity and applicability of our results. To ensure reproducible and statistically robust evaluation, each simulation configuration was executed for 20 independent runs using different random seeds for mobility traces, vehicle positions, and microservice-placement events The results are reported as mean values with 95% confidence intervals. The results include these confidence intervals as error bars.

5.1. Scenario 1

This scenario is designed to assess the performance improvement offered by the proposed AABTM architecture over centralized implementation. The simulation environment for scenario 1 is aligned with the EUA dataset, having 118 RSUs positioned at 12 different microzones across the Melbourne Central Business District. In all simulations, the proxy server (tier-1 nodes) is connected to the cloud server (tier-0 nodes), with a varying number of vehicles with randomly generated locations. The specifications of the devices used in the evaluations are described in

Table 3. Simulation parameters used during the evaluations.

Resource Type	Cloud Server	Proxy Server	RSUs	Smart Vehicles
Numbers	1	3	13	10–60
Speed (MIPS)	44,800	2800	2800	200
RAM (GB)	40	4	4	2
Uplink (MBPS)	100	10,000	10,000	10,000
Downlink (MBPS)	10,000	10,000	10,000	270
Busy Power (MJ)	107.339	107.339	107.339	87.530
Idle Power (MJ)	83.433	83.433	83.433	82.440

. The specifications are expressed in Million Instructions Per Second (MIPS) for processing speed, while energy parameters are given in Mega Joules (MJ). The duration of all the simulations performed is 20,000 s. The specifications of the microservices deployed during the evaluations are described in

Table 4. Specifications of the microservices placed during the evaluations.

Module	RAM(MB)	CPU Length (MI)	Size (MB)
Vehicle	128	150	100
Data Collection	512	250	200
Microzone Traffic	512	350	200
Emergency Control	512	350	200
Storage	128	250	200

. The scenario is evaluated with a variable number of vehicles (10–34). The results of multiple simulations illustrate that the proposed scheme outperforms the centralized urban traffic management approach against various vital network metrics. The proposed decentralized microzone-based architectural approach achieves a significant reduction in average latency and network consumption. Further results are discussed in the subsequent subsections.

5.2. Scenario 2

To evaluate the proposed policies in an adaptive area-based framework, we performed multiple simulations using the same parameters as described in Table 3 and Table 4. In all our evaluations, we have divided the large urban area into three/multiple management units called microzones, with one proxy server per microzone. Each microzone contains thirteen fog nodes as RSUs for processing traffic information. We have performed simulations with a varying number of vehicles (from 10 to 60). The dynamic vehicular clustering (DVC) algorithm, along with the dynamic microservice assignment (DMA) algorithm, called DMA-clustering, is employed to manage communication, energy consumption, network load, and execution costs for the vehicles.

6. Results and Discussion

This section presents the results of the evaluations performed on multiple scales for both scenarios.

6.1. Results for Scenario 1

The following subsections briefly present the key performance outcomes observed under Scenario 1.

6.1.1. Latency

We evaluated the proposed vehicle management scheme against the traditional centralized urban traffic management architecture under varying vehicular traffic load conditions. The average delay is considered in the control loop, which in our case consists of Vehicle → Data Collection → Microzone Traffic → Emergency Control/Storage. Since this loop is highly latency-sensitive, a lower delay reflects more efficient deployment. The proposed scheme significantly reduces the delay by dividing the urban traffic load across different microzones and providing information processing near the network edge, as shown in Figure 4.

6.1.2. Network Usage

The distribution of the urban vehicular information load across various resource-constrained distributed nodes reduces the burden on the network. As compared to the centralized processing, the distributed network nodes only have to process the information of their relevant microzone, thus providing a significant reduction in network utilization, as shown in Figure 5. Additionally, processing near the vehicular infrastructure also reduces the unnecessary data transfer between tiers; therefore, it is a suitable choice for large-scale deployment and reliable network performance.

6.1.3. Energy Consumption

Figure 6 illustrates the energy consumed across different evaluations performed under different traffic conditions. The results show that energy usage depends on the number of microservices running on each tier. The proposed adaptive area-based deployment provides enough resources per area to minimize the recursive processing requests to upper tiers, providing a significant reduction in energy consumption.

6.1.4. Execution Cost

The distribution of the urban traffic load into multiple units reduces the processing load on the network devices. This distribution of resources throughout the network and provision of processing near the network edge reduces the burden on the network. In the AABTM framework, most of the processing is performed through the distributed fog/edge nodes. This distributed provision of processing near the edge significantly reduces the execution cost. In a distributed architecture, network nodes only have to process the information of their relevant microzone, thus providing a significant reduction in processing cost, as shown in Figure 7. Additionally, processing near the vehicular infrastructure also reduces the unnecessary transfer of information between tiers; therefore, it is a suitable choice for large-scale deployment and reliable network performance.

6.2. Results for Scenario 2

The following subsections briefly present the key performance outcomes observed under Scenario 2.

6.2.1. Network Utilization

In vehicular edge/fog computing, network usage is a critical metric for evaluating system performance. With an increase in the number of vehicles, the amount of information exchange between vehicles, RSUs, and the cloud grows instantaneously. This information surge can lead to network congestion, service interruptions, and increased latency, particularly in high-density traffic scenarios. Incorporation of DMA-clustering helps to localize communications and optimize the data flow. The provision of information processing at the network edge, efficient microservice migration, and reduction in the unnecessary information transmissions to the cloud server significantly reduce the network congestion, as shown in Figure 8.

6.2.2. Energy Consumption

The energy consumption of a system is a significant factor in evaluating the efficiency of a modular system and depends on the applied microservice placement approach. Figure 9 illustrates that incorporating the DMA-clustering approach provides reduced energy consumption as compared to the Edgward placement. The cloud server and proxy nodes consume less energy while incorporating the DMA-clustering approach as compared to the Edgeward placement.

Figure 10 illustrates the overall reduction in energy utilization through the incorporation of the DMA-clustering strategy. This reduction is due to the efficient assignment and migration of microservices throughout the cluster. The proposed approach optimizes the network scalability and ensures a gradual increase in energy consumption with an increase in the vehicular load. The proposed approach provides an efficient and scalable solution for the implementation of a traffic management system.

6.2.3. Execution Cost

With an increase in vehicular traffic, there is an increase in the execution cost, as shown in Figure 11. The DMA-clustering approach efficiently manages the cluster formation and task allocation to ensure that processing loads are balanced and there is a controlled growth of execution cost rather than exponentially. Furthermore, this approach enhances the efficiency of the network through localizing communications and reducing reliance on a centralized infrastructure.

The incorporation of DMA-clustering dynamically adjusts the communication, energy consumption, network, and microservice allocation for efficient real-time traffic management. This results in an improved network performance, making the system scalable, cost-efficient, and well-suited for dynamic vehicular environments. As compared to Edgeward placement, the DMA-clustering achieves an average reduction of 59.2% in network consumption. Moreover, a 5% reduction in energy consumption and a 38.39% reduction in execution cost are also observed.

Table 5. Performance comparison between proposed schemes.

Algorithm	Primary Function	Performance Gains	Improvement
VMM	Seamless service migration based on vehicle speed, location, and RSU load	Contributes to 86.4% latency reduction and 53.3% lower network usage	Improves RSU assignment and reduces handover delay
DVC	Groups RSUs based on proximity, communication range, and latency	Contributes to 59.2% network reduction and 5% energy reduction	Enhances V2I performance and cluster-based RSU efficiency
DMA	Resource-aware microservice placement and migration	Achieves 59.2% network reduction, 5% energy savings, and 38.4% execution cost reduction	Reduces inter-tier communication and improves load balancing

presents the performance comparison between proposed schemes.

7. Conclusions

In this research, we have implemented an adaptive area-based traffic management framework for efficient vehicular management. The employed framework divides the metropolitan area into smart zones that are supervised using a decentralized computing approach. We proposed a mobility management scheme for seamless service migration between the RSUs, considering the location and speed of vehicles. Then, we proposed a dynamic clustering algorithm that groups the RSUs based on proximity, communication range, and offered latency to ensure efficient and reliable V2I communication. Finally, we presented a dynamic microservice assignment scheme that ensures the effective placement of microservices, according to the availability of resources and the location of network nodes. We have evaluated the proposed schemes on multiple scales, incorporating the EUA Dataset, containing location information for the edge/fog nodes deployed across different regions of major cities in Australia. The results illustrate that the proposed framework significantly outperforms traditional vehicular architectures in terms of various performance metrics. The proposed AABTM and DMA-clustering schemes significantly improve the implementation of an intelligent vehicular management system through the provision of a scalable and efficient architecture. The proposed schemes provide significant improvement in vital network parameters. AABTM achieves reductions of 86.4% in latency, 53.3% in network consumption, 6.2% in energy usage, and 48.3% in execution cost, while DMA-clustering reduces network consumption by 59.2%, energy usage by 5%, and execution cost by 38.4% compared to traditional cloud-based urban traffic management frameworks.

7.1. Limitations

This study operates under several simplifying assumptions that may limit full real-world generalization. The infrastructure model assumes fixed RSU placements, stable connectivity, and uniform computing resources within each microzone, which may not reflect heterogeneous city deployments. The evaluation relies on simulation using iFogSim2 and the EUA dataset, which provide realistic spatial constraints but do not capture dynamic traffic behaviors, wireless interference, or failure scenarios. The mathematical modeling also simplifies the latency and cost components, omitting congestion effects and fine-grained mobility variability. These constraints indicate that additional validation using integrated mobility simulators and field-level datasets is required to fully assess the deployment-scale performance.

7.2. Future Directions

The framework shows strong improvements but is limited by simplified iFogSim2 simulations, controlled experimental conditions, and EUA data that do not reflect real-world variability. These constraints indicate the need for future field validation using diverse datasets and resilience-focused designs. We have planned to integrate a complete mobility simulator (SUMO/Veins) with our VEFC architecture to enable more realistic traffic-flow modeling, vehicular trajectories, and mobility-aware validation. Our future work will be focused on the design of lightweight machine learning-based approaches for module placement and migration. Additionally, more robust algorithms will be developed for large-scale vehicular systems for reliability [33,34], scalability, and adaptability. We aim to apply federated learning for secure privacy-preserving decisions in the future, using distributed machine learning modules in iFogSim, and use autonomous agent coordination through multi-agent fog controllers to improve the resilience in multi-tier vehicular fog migration. Future work can focus on further improving the scalability of the proposed framework by exploring the integration of more sophisticated machine learning algorithms for real-time traffic prediction and congestion management. We also plan on integrating vehicle location prediction models [35] to improve the performance of mobility management and resource allocation. Moreover, in the future, we plan to conduct a more detailed analysis of real-world deployment costs, communication overhead, and large-scale scalability to further validate the practicality of the microzone architecture.