Digital Twin in Vehicular Communications: Challenges and Opportunities

Abstract

Digital twins (DTs) are increasingly studied together with vehicular communications, but the literature spans different twinned entities, synchronization assumptions, computing placements, and levels of experimental evidence, which makes results difficult to compare. This survey provides a communication-centric review of DT-enabled vehicular systems. We first introduce an operational definition for a vehicular DT and distinguish a synchronized DT from a static simulator or digital model. We then organize the field according to twin granularity, physical–virtual synchronization, vehicle–edge–cloud placement, enabling V2X technologies, and measurable evaluation dimensions. The standardization discussion is updated from DSRC and IEEE 802.11p through 5G-Advanced and ongoing 3GPP work toward 6G, together with recent digital-twin and network-digital-twin standards. Rather than treating reported benefits as established outcomes, we compare the assumptions, metrics, evidence, limitations, deployment constraints, and safety and security implications of representative studies. Finally, we identify research priorities involving synchronization staleness, twin placement and migration, communication–computation–fidelity tradeoffs, validation and uncertainty, interoperable data models, lifecycle management, and safety-aware closed-loop operation. The survey is intended to provide researchers and practitioners with a structured basis for deciding when DT techniques are appropriate for vehicular communication systems and how such systems should be evaluated.

1. Introduction

Vehicular communication systems are evolving from a safety-message exchange toward connected and automated mobility in which vehicles, roadside infrastructure, edge servers, cloud platforms, and traffic-management systems continuously exchange heterogeneous data. This evolution increases the importance of communication reliability, update freshness, computational placement, and security under mobility [1,2]. At the same time, digital twin (DT) techniques are being adopted to maintain virtual representations of physical assets and systems that can support monitoring, prediction, optimization, and, in some cases, feedback to the physical system [3,4]. The combination of these two areas is attractive but technically nontrivial. A vehicular DT depends on communication to acquire observations and maintain alignment with its physical counterpart, while the resulting virtual model can in turn support network-state estimation, resource allocation, mobility management, or service optimization [5,6]. Consequently, the quality of a DT-enabled vehicular service is determined not only by model accuracy, but also by when data are generated, transported, processed, incorporated into the twin, and acted upon. A high data rate alone does not guarantee a fresh or reliable twin state because queuing, retransmission, computation, model-update time, and mobility-induced handover can all contribute to end-to-end staleness.

A central problem in the existing literature is that the term “digital twin” is used for technically different objects and levels of maturity. Studies may twin a vehicle component, an entire vehicle, a communication network, a fleet, a traffic system, or a city-scale mobility process. Moreover, a static simulator, a periodically calibrated digital model, and a closed-loop synchronized twin do not provide the same capabilities. This survey therefore adopts an explicit operational scope: a vehicular DT must maintain a persistent virtual representation of a physical vehicular or communication entity whose state is updated from physical observations over time; the representation is used for monitoring, prediction, optimization, or decision support, and may optionally provide feedback to the physical system. Static simulation models without a continuing physical–virtual update relationship are treated as supporting tools rather than full DT implementations. Figure 1 illustrates the physical–virtual communication setting considered in this survey.

1.1. Scope, Intended Readership, and Distinction from Existing Surveys

For reference, the abbreviations used throughout this survey are summarized in

Table 1. Abbreviations used in this survey.

Abbreviation	Definition	Abbreviation	Definition
DT	Digital Twin	V2V	Vehicle-to-Vehicle
V2I	Vehicle-to-Infrastructure	V2N	Vehicle-to-Network
V2X	Vehicle-to-Everything	C-V2X	Cellular Vehicle-to-Everything
DSRC	Dedicated Short-Range Communications	QoS	Quality of Service
NR	New Radio	AI	Artificial Intelligence
KPI	Key Performance Indicator	IoT	Internet of Things
AR	Augmented Reality	VR	Virtual Reality
MEC	Mobile Edge Computing	mmWave	Millimeter-Wave
RSU	Roadside Unit	RAN	Radio Access Network
DTN	Digital Twin Network	AoI	Age of Information
ISAC	Integrated Sensing and Communication	GDPR	General Data Protection Regulation
IoV	Internet of Vehicles	VEC	Vehicular Edge Computing
FL	Federated Learning	UAV	Unmanned Aerial Vehicle

. Recent reviews have examined DTs from several neighboring perspectives, including the Internet of Vehicles [7], vehicular prototyping [8], transport planning [9], DT-enabled edge resource management for the IoV [10], intelligent vehicles and transportation systems [11], transportation-oriented DT models [12], and connected vehicle–driver–road twins [13]. These studies demonstrate the rapid maturation of the field, but they also make the remaining scope of this survey more specific. As summarized in

Table 2. Comparison of recent reviews related to digital twins and vehicular/transportation systems.

Review	Primary Scope	V2X/Net.	Sync.	Place.	Std.	Eval.	Life.
Guo et al. [7] (2024)	Vehicles and IoV integration	P	–	–	–	P	P
Kabir et al. [8] (2025)	Vehicle/component prototyping	P	–	–	–	P	–
Nag et al. [9] (2025)	Transport planning and mobility twins	–	–	–	–	P	–
Xie et al. [10] (2025)	Edge DTs for IoV resource management	C	P	P	–	P	P
Gu et al. [11] (2026)	Intelligent vehicles and transportation systems	P	P	P	P	P	P
Xing et al. [12] (2026)	Transportation-system DT architecture	P	P	–	–	P	–
Kaya et al. [13] (2026)	Vehicle–driver–road multi-twin systems	P	P	–	–	P	C
This survey (2026)	Vehicle, communication-network, and fleet/traffic twins	C	C	C	C	C	C

Notation: C = central organizing dimension; P = partially covered/supporting topic; – = not a central comparison dimension. Place. = placement/migration; Eval. = metrics/validation; Life. = lifecycle/safety. The table clarifies scope rather than ranking prior reviews.

, our emphasis is not DT technology for transportation in general; it is the communication-centric coupling between a physical vehicular system and its twin. We therefore focus on how V2X connectivity, synchronization and staleness, edge/cloud placement and migration, communication–computation coupling, communication standards, network-facing KPIs, lifecycle management, security, validation, and deployment constraints determine whether a vehicular DT can operate reliably. The primary readers are expected to be researchers in vehicular communications, V2X networking, mobile/edge computing, digital twins, and intelligent transportation systems, together with engineers and practitioners involved in connected-vehicle platforms, roadside and edge infrastructure, and network standardization. A communication researcher should be able to identify which DT functions create new traffic and latency requirements; a DT researcher should be able to identify which communication assumptions determine synchronization quality; and a system designer should be able to map an application to an appropriate twin granularity, placement, update mechanism, evaluation metric, and safety level. Accordingly, the survey is organized around design choices and evidence rather than only around lists of enabling technologies. The main contributions of this survey are as follows:

• We establish an operational definition and scope for vehicular DTs and introduce a granularity-oriented taxonomy that distinguishes component, vehicle, communication-network, fleet/traffic, and city-scale twins according to their physical subject, update relationship, communication role, and decision authority.
• We provide a communication-centric synthesis of DT architectures, emphasizing physical–virtual synchronization, state staleness, twin placement and migration, V2X connectivity, and vehicle–edge–cloud coordination rather than treating communication as a generic enabling layer.
• We update the standards discussion through 5G-Advanced and ongoing 3GPP 6G work, and relate recent DT/network-DT standards to interfaces, data domains, synchronization, and security requirements relevant to vehicular systems.
• We develop an orthogonal challenge taxonomy spanning communication and synchronization, twin-model validity and data quality, communication–computation coupling, lifecycle and state management, safety, security, and privacy, together with deployment, interoperability, and governance. We further define measurable DT/network metrics and distinguish reported benefits from demonstrated evidence.
• We organize future work as an evidence-driven research agenda in which open questions are linked to limitations observed in the surveyed literature, with near-term engineering problems separated from longer-term research opportunities.

1.2. Literature Review Methodology

To provide a transparent literature basis while keeping the review narrative rather than PRISMA-based, we conducted a structured search focused on communication-coupled vehicular DTs. The search covered IEEE Xplore, Scopus, Web of Science, ScienceDirect, and Google Scholar and focused primarily on studies published from 2018 through August 2026, while retaining earlier seminal work needed for technical background. Representative Boolean search groups were of the form: (“digital twin” AND (vehicle OR vehicular OR V2X OR “Internet of Vehicles”)); (“digital twin” AND (“communication network” OR C-V2X OR “NR V2X” OR sidelink)); (“digital twin” AND (edge OR MEC OR synchronization OR migration OR offloading OR “resource allocation”)); and (“digital twin” AND (security OR privacy OR validation OR standardization OR safety OR lifecycle)).

The initial search returned several hundred candidate records. Duplicates were removed by DOI/title matching, after which titles and abstracts were screened for technical relevance. Full texts were then examined to confirm whether the work addressed a DT in a vehicular, transportation, or communication context and contributed substantive evidence on at least one aspect of physical–virtual updating, synchronization, architecture or placement, communication dependence, feedback or decision support, evaluation, or deployment. Static simulation or optimization models without a continuing physical–virtual update relationship were not treated as full DT implementations, although they could be cited as supporting tools. Non-vehicular studies were retained only when a transferable mechanism was directly relevant to vehicular DTs, for example lifecycle management or safety assurance. The search was supplemented by backward and forward citation tracing from the closest recent surveys.

For the comparative synthesis presented later in Section 4, representative studies were selected to span the main twinned entities, placement patterns, synchronization or migration mechanisms, communication technologies, and evidence levels discussed in Section 4 and Section 5. The selection therefore reflects technical representativeness and evidence diversity rather than recency or citation count alone. The resulting literature base supports a qualitative technical synthesis rather than a statistical meta-analysis; accordingly, references to “recent”, “representative”, or “surveyed” literature in this paper should be understood as scoped to this structured search rather than as a claim of exhaustive systematic completeness.

The remainder of this paper is organized as follows. Section 2 establishes the communication and DT foundations, the operational scope, current standards, and evaluation dimensions. Section 3 analyzes the challenges of coupling communication networks with DTs. Section 4 reviews representative architectures and enabling technologies. Section 5 examines application evidence and practical implications. Section 6 develops the research agenda, and Section 7 concludes the paper. Figure 2 summarizes this analytical flow.

2. Background, Scope, and Evaluation Foundations

2.1. Vehicular Communication Standards and Evolution

2.1.1. From DSRC to 5G-Advanced and Emerging 6G

Vehicular communications have evolved through two main technology families: IEEE 802.11 [14]-based vehicular access and 3GPP cellular V2X. DSRC/WAVE [15,16] and IEEE 802.11p [17] established direct short-range V2V and V2I communication in the 5.9 GHz band, while IEEE 802.11bd [18] subsequently enhanced throughput, reliability, and backward-compatible operation for more demanding cooperative applications [19]. In parallel, 3GPP introduced LTE C-V2X for direct sidelink and network-assisted V2X, followed by NR V2X in Release 16 and further sidelink enhancements in Release 17 [20,21,22,23]. Figure 3 updates the standardization timeline beyond 2022. According to the 3GPP release portal, Release 18 was frozen in June 2024 and Release 19 in December 2025, while Releases 20 and 21 remain open [24]. Release 18 marks the first 5G-Advanced release and includes continued sidelink evolution together with enhancements relevant to relay and positioning. Release 19 continues 5G-Advanced evolution. Release 20 combines further 5G-Advanced technical work with early 6G studies, whereas Release 21 is the first release in which 3GPP plans normative 6G specification work [25]. The distinction is important: Release 20 should not be described as a completed 6G standard, and Release 21 remains an open standardization activity at the time of writing.

These standardization steps matter to vehicular DTs because synchronization depends on the availability, timeliness, and reliability of physical-state updates. Enhanced sidelink operation, relay functions, positioning, and edge-assisted connectivity can expand the set of observations that a twin receives and can reduce communication delay under appropriate conditions. However, improved radio data rate or nominal air-interface latency does not automatically imply a fresher twin. Queueing, retransmissions, sensing intervals, edge processing, model-update complexity, and mobility-induced service interruption jointly determine the age of the state represented by the twin. For this reason, the remainder of the survey separates radio/network KPIs from DT synchronization and model-quality metrics instead of assuming a deterministic causal relation between them.

2.1.2. Vehicular Communication Requirements for DT Operation

Vehicular communication provides the observation and feedback paths required by a communication-coupled DT. Conventional radio metrics such as data rate, latency, reliability, and coverage therefore remain important, but they should be interpreted according to how they affect the physical–virtual update process rather than as independent indicators of DT quality. A high-rate link can transport richer sensing or model data, for example, but the resulting twin state may still be stale if channel access, retransmission, queueing, edge processing, or model integration dominates the update cycle [26,27].

Mobility makes these requirements time-varying. Rapid changes in channel quality, interference, cell association, and topology can interrupt or delay updates even when the average link quality is acceptable. Safety-related cooperative services may require bounded update latency and high delivery reliability, whereas traffic monitoring or predictive maintenance can tolerate slower updates but may require wider spatial coverage, long-term consistency, or larger data volumes [28,29]. Consequently, the communication requirement of a DT is application specific and should be stated together with the twin-update interval, the maximum acceptable state age, and the decision timescale.

The evolution toward 5G-Advanced and 6G expands the available communication, sensing, and edge-computing capabilities, including enhanced sidelink operation, positioning, integrated sensing and communication, and more distributed intelligence. These capabilities can improve DT observability and reduce individual communication bottlenecks, but they also introduce additional coupling among sensing rate, radio-resource usage, computation load, and model-update complexity. For this reason, later sections evaluate DT-enabled vehicular systems using communication, synchronization, model-quality, computation, and lifecycle metrics jointly rather than assuming that improvement in a single radio KPI necessarily produces a better twin.

2.2. Digital Twin Definition, Scope, and Standardization

2.2.1. Operational Definition and Survey Boundary

A DT should not be identified only by the fidelity of a virtual representation. For this survey, a vehicular digital twin is a persistent virtual representation of a physical vehicular entity or communication system whose state is continuously or periodically updated from physical observations and whose evolving model is used for monitoring, estimation, prediction, optimization, or decision support. Feedback from the virtual side to the physical system may be advisory or closed-loop. This definition requires an explicit physical–virtual update relationship; a one-off simulator, a static digital model, or an optimization model that is not maintained using observations from the physical counterpart is therefore treated as a DT-supporting tool rather than a complete DT. This operational boundary is consistent with recent terminology and network-DT standardization that emphasizes data, models, interfaces, and interactive mapping between physical and virtual systems [30,31]. Figure 4 summarizes the corresponding distinction among a digital twin, a cyber twin, and a simulation.

The object being twinned is equally important.

Table 3. Operational taxonomy of vehicular digital twins used in this survey.

Twin Class	Physical Subject and Update	Communication/Decision Role
Component twin	Battery, sensor, radio, drivetrain, or other subsystem; event-driven or periodic telemetry	Vehicle-internal link or uplink; diagnosis, maintenance, and local adaptation
Vehicle twin	Whole-vehicle operational state; continuous or periodic physical–virtual synchronization	V2N/V2I/V2V and edge/cloud exchange; monitoring, cooperative perception, trajectory/service optimization
Communication-network twin	RAN/V2X links, RSUs/BSs, edge resources, topology, and traffic state; multi-timescale telemetry	The network is the twinned object; estimation, resource control, coverage/interference analysis, and policy testing
Fleet/traffic twin	Multiple vehicles, fleet state, traffic flow, and road interactions; aggregated multi-vehicle updates	Multi-source V2X with edge/cloud aggregation; fleet coordination, routing, traffic management, and system-level prediction
City-scale mobility twin	Transport infrastructure and multi-modal mobility ecosystem; heterogeneous multi-domain updates	Vehicular communication is one data/actuation fabric; urban planning and cross-system coordination

distinguishes five granularities that recur in vehicular research. The classes are related but should not be treated as interchangeable because they differ in data ownership, update frequency, communication path, validation target, and decision authority. In this survey, component- and city-scale studies are included only when their findings materially affect vehicular communication or the operation of communication-coupled twins.

2.2.2. Digital Twin and Network-Digital-Twin Standards

Standardization after 2022 provides a clearer basis for distinguishing a DT from a generic digital model. ISO/IEC 30173:2023 establishes DT concepts and terminology, while ISO/IEC TR 30172:2023 collects representative DT use cases [30,32]. For communication networks, ITU-T Y.3090 defines digital twin network (DTN) requirements and an architecture based on data, models, interfaces, and real-time interactive mapping [31]. ITU-T X.2011 (2024) specifies DTN security threats, requirements, and countermeasures; ITU-T Y.3093 (2025) further specifies the data-domain framework, interfaces, compatibility, and security considerations; and ITU-T X.2014 (2026) addresses the use of network digital twins for network-security applications [33,34,35]. Figure 5 summarizes these milestones and their relevance to vehicular DTs.

For vehicular communications, these standards do not prescribe a complete automotive DT architecture, but they expose interfaces that a practical design must address: trustworthy data acquisition, data/model semantics, synchronization between physical and virtual states, cross-platform compatibility, and secure control interaction. We therefore use these functions as evaluation dimensions later in the survey instead of treating standardization only as a list of document names.

2.2.3. Evolution and Enabling Technologies of Digital Twins

The idea underlying a digital twin predates the term itself. During the Apollo program, mirrored physical systems on Earth were used to reproduce spacecraft conditions and support diagnosis, which is often viewed as an early precursor to the modern DT concept [36]. In the early 2000s, Grieves formalized the idea of maintaining a digital representation associated with a physical product or system [3,37]. These developments established two ideas that remain important for vehicular DTs: a physical counterpart must be represented in the digital domain, and the representation becomes useful only when it can be updated and used throughout operation.

The rapid growth of the Internet of Things (IoT) expanded the amount and diversity of observable physical data [38,39,40,41]. Cloud computing subsequently provided scalable storage and processing for these data streams, while artificial intelligence enabled state estimation, prediction, anomaly detection, and optimization [42,43]. Together, these technologies moved DTs from largely offline representations toward continuously updated and increasingly predictive systems. However, IoT connectivity, cloud processing, or AI alone does not make a system a DT; the defining element remains the maintained physical–virtual relationship introduced in Section 2.2.1.

For vehicular systems, the evolution is further shaped by mobility and distributed communication/computing infrastructure. A vehicle, roadside unit, radio access network, or traffic process can generate rapidly changing observations that may be processed on board, at an edge server, or in the cloud. Consequently, a vehicular DT is not simply a centralized model of a vehicle. Its quality also depends on V2X data acquisition, communication delay and reliability, computation placement, synchronization frequency, model-update latency, and the authority of any feedback sent to the physical system. This communication-centric view motivates the layered architecture used in this survey.

Visualization technologies such as AR/VR can provide useful interfaces to a DT [44,45], but they are application interfaces rather than defining components. Similarly, increasingly capable AI models may improve prediction or control, yet their contribution must be distinguished from the persistent physical–virtual update mechanism itself. This distinction is particularly important in vehicular research, where a simulator or learned policy can support a DT without constituting the DT on its own.

2.2.4. Layered Architecture Perspective

A common generic DT abstraction contains physical, connectivity, and digital layers [46,47,48,49,50,51,52,53,54]. The physical layer contains the asset and sensing/actuation interfaces, the connectivity layer transports observations and commands, and the digital layer maintains the virtual representation and associated analytics. This abstraction remains useful, but vehicular communication systems require a finer separation between wireless connectivity, distributed computing, twin-model operation, and application-level decision making.

Figure 6 therefore expands the generic three-layer view into five communication-centric layers for vehicular DTs.

• Physical Vehicular Layer: The physical layer contains vehicles, onboard sensors and actuators, roadside units, base stations, and transportation infrastructure. These entities generate kinematic, environmental, traffic, and network observations and may also receive control or service decisions from the virtual side.
• V2X Communication Layer: The communication layer carries physical-to-virtual observations and, when feedback is enabled, virtual-to-physical decisions. It includes V2V, V2I, and V2N links over interfaces such as PC5 and Uu, together with multicast/broadcast and network-assisted communication. Reliability, latency, data freshness, mobility support, security, and privacy at this layer directly affect whether the twin state remains usable.
• Edge–Cloud Computing Layer: Vehicular DT functions can be placed on board, at RSU/MEC nodes, or in centralized cloud platforms. Onboard execution minimizes external communication dependence but has limited resources; edge execution can support low-latency local services; and cloud platforms provide larger shared computing and storage resources for global or long-horizon tasks. The placement decision therefore couples communication delay, computing load, migration overhead, energy consumption, and model consistency.
• Digital Twin Layer: The DT layer maintains the evolving virtual representation. Core functions include state synchronization, model updating, prediction and scenario analysis, and uncertainty/validation management. The layer should not be evaluated only by nominal model fidelity: freshness, calibration, consistency, and the communication/computation cost required to maintain the model are equally important.
• Application and Decision Layer: Twin states and predictions support application-specific functions such as communication-resource allocation, cooperative driving, traffic management, and predictive maintenance. Feedback may range from advisory recommendations to closed-loop control. The required synchronization bound, model confidence, reliability, and fail-safe behavior therefore depend on the authority and safety criticality of the application.

The architecture also contains cross-cutting concerns that cannot be assigned to only one layer. Security and privacy protect the physical–virtual data path; interoperability and data semantics determine whether heterogeneous platforms can exchange state consistently; lifecycle mechanisms maintain identity, version, placement, migration, and retirement; and validation determines whether a twin remains trustworthy as the physical system and environment evolve. These concerns are analyzed in greater detail in Section 3 and Section 4.

2.2.5. Lifecycle-Oriented Perspective

A lifecycle-oriented view complements the layered architecture by describing how a twin evolves over time [55,56,57,58]. For vehicular DTs, the lifecycle is not limited to design and maintenance of a physical product; mobility and distributed infrastructure make operational lifecycle management a continuous networking problem. The principal stages include:

• Instantiation and Binding: A twin is created, associated with its physical vehicle, component, network element, or traffic entity, and assigned identities, access rights, and initial models.
• Calibration and Operational Synchronization: Physical observations are incorporated into the twin, model parameters are calibrated, and the virtual state is maintained at an application-appropriate freshness and fidelity.
• Placement, Replication, and Migration: Twin functions or replicas may move among vehicle, edge, and cloud nodes as mobility, load, and service requirements change. These operations introduce transfer overhead and state-consistency requirements.
• Model and Software Evolution: Models, interfaces, and software can be updated as sensors, communication capabilities, environments, and service requirements change. Version compatibility and validation are therefore part of long-term operation.
• Retirement and Archival: A twin or one of its service instances must eventually be decommissioned, with explicit handling of retained data, credentials, historical models, and ownership obligations.

This lifecycle perspective explains why twin placement, migration, versioning, and consistency are treated as a dedicated challenge in Section 3.4 rather than as one-time implementation choices.

2.2.6. Function-Oriented Perspective

A function-oriented view classifies what a DT does rather than where a function is placed [59,60,61,62]. In vehicular communication systems, the principal functions can be organized as:

• Representation and State Estimation: Maintain a task-relevant representation of the physical entity and infer unobserved or noisy states when necessary.
• Data Aggregation and Synchronization: Fuse observations from vehicles, infrastructure, network telemetry, and other twins while preserving timing, provenance, and consistency.
• Prediction and Analysis: Forecast mobility, communication state, traffic evolution, failures, or resource demand and evaluate alternative scenarios.
• Optimization and Decision Support: Use the synchronized/predicted state for resource allocation, mobility management, cooperative services, or maintenance decisions.
• Feedback and Actuation: Return recommendations or control actions to the physical system when the application permits closed-loop operation.

These functions may span multiple layers in Figure 6. For example, state synchronization involves sensing, V2X transport, edge/cloud processing, and model updating, while a closed-loop resource decision further involves application logic and a feedback path. The layered, lifecycle, and function-oriented perspectives are therefore complementary rather than competing DT taxonomies: the layered view identifies where functions operate, the lifecycle view identifies when and how the twin is maintained, and the function-oriented view identifies what the twin performs.

2.3. Evaluation Metrics for Vehicular Digital Twins

A DT-enabled vehicular system must be evaluated across at least three coupled layers: the communication path, the virtual model, and the computation/control loop. A single qualitative label such as “high fidelity” or “low latency” is insufficient for comparison.

Table 4. Core evaluation metrics for DT-enabled vehicular communication systems.

Metric	Operational Definition	Minimum Reporting Requirement
Synchronization latency	Time from physical observation generation to incorporation into the active twin	Mean and tail/violation statistics; sensing, transmission, processing, and model-update components
Twin-state age/staleness	Age of the freshest incorporated state, e.g., $\Delta \left(t\right)=t-u\left(t\right)$	Mean/percentile or deadline-violation probability under the stated update process
Update reliability	Probability that a required update is delivered and incorporated before its deadline	Deadline definition and on-time update ratio; distinguish from link-level packet reception
Model fidelity and uncertainty	Error between physical measurements and the corresponding twin state/prediction	Compared variables, RMSE/MAE or task metric, prediction horizon, and uncertainty/calibration where applicable
Computation/update latency	Preprocessing, inference, simulation/optimization, and model-update time	Hardware/model size and latency distribution
Communication/migration overhead	Telemetry, model synchronization/control traffic, and transferred state during migration	Average/burst traffic, transferred state size, interruption time, and consistency mechanism
Energy efficiency	Energy used by sensing, communication, and computation for a useful DT update/service	J/update, J/task, or W with a stated vehicle/network accounting boundary
Availability/resilience	Fraction of time the DT service satisfies its operating condition and recovers after failure	Availability, recovery time, disconnection/stale-state handling, and degraded-mode behavior
Deployment cost	Infrastructure and operating resources required for the DT service	RSU and edge-server assumptions, backhaul, resource use, maintenance, and CAPEX/OPEX where

therefore defines measurable quantities or evaluation proxies that can be reported consistently. Exact thresholds remain application dependent; for example, a safety-related cooperative-driving twin and a fleet-maintenance twin need not use the same update period or latency budget.

These metrics are coupled but the coupling should not be described as universal causality. Increasing update frequency can reduce staleness only when communication and computation capacity are sufficient; otherwise it can increase queuing and contention. A higher-fidelity model can reduce representation error but may increase computation time, model-transfer overhead, and energy consumption. Moving a twin closer to the vehicle can reduce propagation and backhaul delay but may increase migration frequency and edge-resource fragmentation under mobility. Security and privacy mechanisms can also add computation and signaling overhead, while insufficient protection can invalidate the trustworthiness of the physical–virtual feedback loop. Consequently, the appropriate design target is an application-specific operating point that jointly satisfies the required synchronization, fidelity, communication, computation, safety, and cost constraints, rather than independent maximization of individual KPIs. These coupled relations are summarized conceptually in Figure 7.

2.4. Application Classes and Requirement Heterogeneity

The relevance of each metric depends on the application.

Table 5. Application-to-design mapping for representative vehicular DT services.

Application	Primary Twin Object	Timing/Placement	Dominant Design Requirement
Cooperative/automated driving	Vehicle + local environment	Very frequent updates; on-board + nearby edge; PC5/Uu	Freshness, reliability, uncertainty handling, and fail-safe behavior
Traffic management	Fleet/traffic + road infrastructure	Medium–high update rate; edge + cloud; V2I/V2N aggregation	Spatial coverage and multi-source consistency
Fleet monitoring/coordination	Fleet + vehicle	Medium update rate; edge/cloud; mainly V2N	Scalability, lifecycle, ownership, and intermittent connectivity
Predictive maintenance	Component/vehicle	Low–medium update rate; on-board, edge, or cloud	Long-horizon fidelity, calibration, provenance, and uncertainty
Communication-network optimization	RAN/V2X network	Multi-timescale updates; edge/network controller	Network-state freshness, trustworthy telemetry, update latency, and safe policy deployment

provides a requirements-to-design mapping that is used later when interpreting reported case studies. The entries are qualitative because comparable numerical thresholds are not consistently reported across the surveyed literature; a key need identified by this review is therefore application-specific benchmarking.

3. Challenges in Integrating Digital Twin in Vehicular Communications

The challenges of digital-twin-assisted vehicular communications are strongly coupled, but they should not be classified by repeatedly listing the same symptoms under different headings. For example, mobility can cause link interruption; link interruption increases update delay; delayed updates increase twin-state staleness; stale states can reduce model validity and, in a closed-loop system, may lead to unsafe decisions. Likewise, increasing sensing resolution can improve the information available to a twin while simultaneously increasing communication load, edge-computing demand, queuing delay, and energy consumption. Therefore, this section reorganizes the challenges into six primary classes according to the subsystem in which the failure first arises: communication and synchronization, twin-model validity and data quality, computing and communication–computation coupling, lifecycle and state management, safety, security, and privacy, and deployment, interoperability, and governance. Urban, rural, and highway scenarios are treated as operating contexts that change the severity of these challenges rather than as independent challenge classes.

3.1. Communication and Physical–Virtual Synchronization

Communication is not merely a transport layer for a vehicular DT; it determines whether the virtual representation is temporally aligned with the physical system. High vehicle mobility, time-varying channels, interference, cell transitions, and bursty traffic can make physical-to-virtual updates irregular even when the nominal link data rate is high [63,64]. The relevant quantity is therefore not data rate alone. A DT update may traverse sensing, medium access, transmission, retransmission, queueing, edge/cloud processing, and model-update stages before it becomes usable. Consequently, a higher data rate can be an enabling condition for synchronization, but it does not by itself imply lower end-to-end latency or fresher twin state. The latency, reliability, and state-age metrics introduced in Table 4 should be interpreted jointly.

A useful causal view is

$$T_{\mathrm{sync}}=T_{\mathrm{sense}}+T_{\mathrm{access}}+T_{\mathrm{tx}}+T_{\mathrm{queue}}+T_{\mathrm{comp}}+T_{\mathrm{update}},$$

(1)

where the terms represent sensing, channel access, transmission, queueing, computation, and twin-update delays, respectively. Equation (1) is a stage-wise decomposition rather than a universal stochastic latency model. Mobility, handover, packet loss, and congestion affect the total delay by changing one or more of these components. For example, handover can increase $T_{\mathrm{access}}$ and $T_{\mathrm{tx}}$, retransmission increases $T_{\mathrm{tx}}$, and congestion increases $T_{\mathrm{queue}}$. Likewise, denser sensing can improve observability while increasing communication and processing load. Figure 8 visualizes this end-to-end update chain.

Several technologies can reduce individual components in the synchronization chain, but each has an applicability condition. MEC can shorten the communication path and support rapid local updates, yet distributed edge processing requires sufficient edge capacity and dependable vehicle–edge connectivity [65,66]. Network slicing can isolate services with different latency and reliability objectives, but slice reconfiguration and resource contention become more difficult under mobility [67,68]. Predictive handover and multi-connectivity can reduce interruption probability, while redundant paths consume additional radio resources and may increase coordination overhead [69,70]. Small cells and dynamic spectrum management can improve coverage and spatial reuse, but they also increase handover frequency and interference-management complexity [71,72]. These mechanisms should therefore be evaluated according to the application requirements in Table 5, rather than being treated as universally beneficial remedies.

Operating context changes the dominant synchronization bottleneck. Dense urban environments offer abundant roadside and cellular infrastructure but create interference, contention, and heterogeneous-data aggregation problems. Rural environments may have lower contention but limited coverage and sparse edge infrastructure, making continuous synchronization difficult. Highways combine high mobility with rapid cell transitions and strict requirements for cooperative-driving services. These contexts modify the parameters of the communication problem; they do not constitute separate technical challenge categories.

3.2. Twin-Model Validity, Validation, and Data Quality

A communication link can deliver updates on time while the DT is still unreliable if the underlying data or model is invalid. Vehicular twins ingest heterogeneous measurements from onboard sensors, infrastructure, neighboring vehicles, and network telemetry, often with different sampling rates, coordinate systems, timestamp quality, and error distributions [73,74,75]. Missing observations, conflicting measurements, sensor bias, and asynchronous timestamps can therefore produce a virtual state that is internally inconsistent even when the communication channel is secure and low-latency.

The first requirement is data quality and provenance. A practical DT should retain enough metadata to determine where an observation originated, when it was produced, how it was transformed, and whether it can be trusted for the current task. Cryptographic integrity protects data against unauthorized modification but does not prove that the physical observation itself is accurate. Likewise, a large volume of sensing data does not necessarily increase twin quality if measurements are redundant, biased, delayed, or semantically incompatible. Data fusion must therefore account for timeliness, source credibility, uncertainty, and semantic consistency rather than treating all received measurements as equivalent [76].

The second requirement is validation over time. Model fidelity should be assessed against physical measurements using task-appropriate errors, confidence intervals, and calibration procedures, rather than being represented by a single qualitative statement such as “high precision.” A model that is accurate under the training or calibration distribution may degrade because of sensor aging, road/environment changes, software updates, vehicle configuration changes, or previously unseen traffic conditions. Vehicular DTs consequently require mechanisms for detecting model drift and out-of-distribution conditions and for deciding when a twin is no longer reliable enough to support a particular decision. This is especially important when a model trained on aggregated or historical data is used for rapidly changing local conditions.

A third issue is the fidelity–freshness–resource tradeoff. High-resolution models and frequent sensing can improve spatial or functional fidelity, but they increase the number of transmitted variables, model-update complexity, storage, and energy demand [77]. For a real-time service, a lower-complexity model updated frequently may be more useful than a highly detailed model whose state is already stale when inference is completed. Hence, DT validation should report both model error and temporal validity, together with the communication and computation resources needed to maintain that validity.

3.3. Computing and Communication–Computation Coupling

DT operation is intrinsically a joint communication and computing problem. Vehicles generate observations, local processors pre-process or infer from them, wireless links transfer data or model updates, and edge/cloud platforms perform aggregation, training, simulation, optimization, or storage. Treating these stages separately can shift delay from one subsystem to another. For example, edge computing is commonly used to reduce propagation latency, but simultaneous offloading by many vehicles can saturate roadside computing resources and introduce queueing delay [78]. Conversely, cloud execution offers larger shared computing capacity but introduces backhaul and transport dependence.

The appropriate placement of a DT function depends on task granularity and deadline. Safety-related state estimation may need vehicle- or edge-side execution, whereas long-horizon global models can tolerate cloud processing. Hybrid edge–cloud designs can maintain local low-latency replicas while using cloud resources for global model training or historical aggregation. However, this architecture creates consistency and coordination traffic between local and global states. AI-based DT functions further increase the coupling because model complexity, training/inference frequency, and communication of parameters or features all affect latency and energy consumption [6,79].

Resource-allocation methods must therefore optimize communication and computation jointly. Offloading to a nearby vehicle can provide opportunistic capacity when an RSU is overloaded, but the available link and computing resources can change quickly with relative motion [78]. Distributed or game-theoretic allocation can model competition among vehicles for radio and computing resources [80], yet its assumptions about information availability, convergence time, and rational behavior must match vehicular timescales. Similarly, federated or distributed learning can reduce raw-data transfer but may introduce repeated model-exchange rounds, straggler effects, and additional synchronization requirements. The relevant question is not whether MEC, AI, or distributed computing is available, but under which load, mobility, and deadline conditions each architecture provides a net system-level benefit.

Energy and sustainability are part of the same coupling. Increasing update frequency, redundancy, model size, or edge replication can improve one performance dimension while increasing radio, computing, and storage energy. Energy efficiency should therefore be evaluated together with achieved twin fidelity and service performance rather than as a standalone infrastructure metric.

3.4. Twin Lifecycle, Placement, Migration, and State Consistency

A vehicular DT is a persistent software/data object whose lifecycle extends beyond a single inference or optimization task. A complete lifecycle includes instantiation, identity binding and authentication, calibration, versioning, replication, placement, migration, reconciliation after disconnection, software/model update, archival, and retirement. High mobility makes these lifecycle operations unusually frequent because the most appropriate edge location for a twin can change as the vehicle moves across coverage areas.

Twin migration has been studied primarily as a latency and handover problem [81,82]. Migrating state to a new edge node can interrupt service and consume radio/backhaul resources, while delayed migration may leave computation far from the vehicle. However, migration latency is only one part of the problem. If source and destination replicas are updated concurrently, the system must define which state is authoritative, how conflicts are resolved, and how partially transferred state is recovered after failure. Data loss, corruption, or inconsistent versioning during handover can invalidate the twin even if the network connection itself remains available [83,84].

Replication creates a related consistency–availability tradeoff. Maintaining multiple edge replicas can improve resilience and reduce future migration delay, but each replica requires synchronization traffic and a consistency policy. Strong consistency can be expensive or temporarily unavailable under intermittent links, whereas eventual consistency may expose applications to stale state. Different vehicular applications therefore require different lifecycle semantics: fleet monitoring may tolerate eventual convergence, while closed-loop cooperative control may require a clearly bounded state age and deterministic failover behavior.

The lifecycle also interacts with ownership and software evolution. Vehicle manufacturers, network operators, road authorities, service providers, and users may each control different parts of the data and model stack. A DT that crosses these administrative domains needs mechanisms for identity, authorization, version compatibility, auditability, and safe retirement. These requirements become particularly important when a long-lived physical vehicle receives sensor, firmware, communication, or AI-model upgrades over many years.

3.5. Safety, Security, and Privacy of the Physical–Twin Loop

Security analysis should protect the complete physical–virtual loop rather than listing attacks on the wireless network and the DT platform independently. Relevant assets include raw sensor observations, vehicle identity and location, twin state, learned model parameters, control recommendations, credentials, and historical data. Trust boundaries may exist between the vehicle, RSU, edge provider, cloud provider, application operator, and other twins. Attack surfaces include onboard sensors, V2X links, APIs, edge/cloud storage, model-update pipelines, and inter-twin communication [85,86,87].

From this perspective, confidentiality, integrity, authenticity, availability, freshness, and authorization are distinct security objectives. Eavesdropping or unauthorized access can reveal location and behavioral information; tampering or replay can make a twin consistent with forged rather than current physical state; denial-of-service can prevent synchronization; and attacks on learning/model pipelines can alter future predictions even after communication is restored [74,88]. Privacy-preserving mechanisms such as anonymization and federated learning can reduce exposure of raw data, but model updates may still leak information and mobility can create stragglers or incomplete training rounds [75,84]. Figure 9 summarizes how these threats propagate across the physical–twin loop and associates each stage with representative protection or assurance mechanisms. Blockchain or distributed-ledger mechanisms can provide tamper-evident records and decentralized trust for selected multi-party interactions [89,90,91], but their consensus, storage, and communication overhead can limit applicability to latency-critical DT functions.

Functional safety is related to, but not identical to, cybersecurity, as highlighted in Figure 9. Even without an attacker, a delayed, erroneous, or over-confident twin can produce an unsafe recommendation. Closing the loop from a virtual model to a physical vehicle therefore requires explicit rules for the authority of the twin. Advisory functions can allow a human or independent controller to reject a recommendation, whereas safety-critical actuation requires stronger evidence of state validity, bounded delay, and model confidence. The system should define fail-safe or fail-operational modes for loss of synchronization, mechanisms for human or supervisory override where appropriate, rollback after faulty model/software updates, and a safe degraded mode when the twin cannot be trusted. These mechanisms are particularly important because stronger automation shortens the time available to detect and correct an erroneous virtual state before it affects the physical system.

A practical security and safety evaluation should therefore connect an attack or failure mode to the affected asset, the resulting state error or service disruption, the decision path that uses that state, and the available recovery mechanism. This causal formulation is more useful for vehicular DT design than a flat inventory of attacks and defensive technologies.

3.6. Deployment, Interoperability, Standardization, and Governance

Even a technically feasible DT architecture may be impractical if it depends on infrastructure density, edge capacity, backhaul, energy supply, or administrative coordination that cannot be sustained at scale. Deployment analysis should therefore include both capital and operational requirements: roadside-unit density, edge-server provisioning, backhaul capacity, storage, maintenance, software/model update burden, energy consumption, and the cost of operating redundant or high-availability infrastructure. These requirements differ substantially between dense urban corridors, highways, and rural regions.

Interoperability is another deployment constraint. Existing DT and network-DT standards define useful concepts, data domains, interfaces, and security requirements [30,31,33,34], but a vehicular deployment still needs mappings between vehicle data models, V2X/network telemetry, twin identifiers, lifecycle operations, synchronization semantics, and control interfaces. Cross-vendor operation is difficult if two platforms use the same term “digital twin” but expose different state definitions, update frequencies, uncertainty representations, or authority models. Standardization should therefore be evaluated at the level of required interfaces and semantics, not only by listing standards documents.

Governance extends this problem across organizational and legal boundaries. Vehicular data may be generated by users, vehicles, road infrastructure, network operators, or third-party services, creating questions of data ownership, permitted reuse, retention, liability, and cross-border compliance. Privacy regulation and safety certification can constrain how data are collected and how much authority a DT may exercise. In addition, industrial deployment requires organizational capabilities for model validation, cybersecurity monitoring, lifecycle management, and incident response rather than only the installation of new computing hardware [92,93].

For industrial stakeholders, the practical implication is that deployment should be incremental and application-specific. A low-risk monitoring or maintenance twin can be introduced with relaxed synchronization and failover requirements, while a safety-critical cooperative-driving twin requires stronger communication guarantees, validation evidence, redundancy, and clearly defined control authority. Pilot deployments should therefore report not only the application KPI but also the infrastructure footprint, update traffic, computing resources, operational cost, maintenance burden, and failure/recovery behavior. These quantities determine whether the reported gain can transfer from a simulation or local testbed to a sustained vehicular service.

3.7. Cross-Cutting Interactions and Design Implications

The six challenge classes defined above are designed to be as orthogonal as possible, but the resulting system behavior is coupled. The key distinction is between cause and symptom. For example, poor radio connectivity is a communication cause; stale twin state is a synchronization symptom; prediction error can be a model-level consequence; and unsafe actuation can be a safety consequence. Similarly, increasing model resolution is a twin-model decision that can raise communication and computing load, which in turn increases queueing and staleness. Statements such as “higher data rate reduces latency” or “low latency improves scalability” are therefore valid only under specified bottlenecks and resource conditions.

This causal view suggests that vehicular-DT design should start from an application requirement and trace backward through the physical–virtual loop. The designer should identify (i) what physical entity is twinned, (ii) how stale or uncertain its virtual state may become before the application becomes invalid, (iii) which communication and computing stages dominate this bound, (iv) how the twin is placed and maintained under mobility, (v) which failures or attacks can corrupt the decision path, and (vi) what infrastructure and governance assumptions are required in deployment. This requirement-to-design mapping provides the basis for comparing the architectures and enabling technologies reviewed in the following section.

4. Recent Advances: Representative Architectures and Comparative Synthesis

The surveyed recent literature shows a shift from using a DT as a generic virtual replica toward using it as an explicit component of vehicular communication and computing control loops. To avoid a study-by-study inventory, this section compares representative work along common dimensions: (i) the entity being twinned, (ii) twin placement and physical–virtual data flow, (iii) synchronization, maintenance, or migration mechanism, (iv) communication and computing technologies, (v) evaluation setting and principal baseline, and (vi) the reported KPI, evidence level, and limitation.

Table 6. Comparative synthesis of representative DT-assisted vehicular communication studies.

Study	Twin Setting/Placement	Sync., Update, or Migration Mechanism	Comm./Compute Technology	Evaluation Setting/Principal Baseline	Reported KPI and Evidence Level	Main Limitation
Jeremiah et al. (2024) [94]	Vehicle/RSU DT with edge collaboration	DT-supported state updates for offloading, RSU association, and subchannel control	VEC, NOMA, edge computing, A2C	Simulation; compared with selected non-DT resource-allocation baselines	Task delay reduced and computation rate improved; evidence level: simulation	Mobility-driven twin-maintenance cost is not the main focus
Kong et al. (2024) [95]	IoV edge-intelligence twin at the edge	DT-assisted energy–delay-aware task-offloading updates	IoV, edge intelligence/ computing	Simulation; compared with conventional task-offloading baselines	Lower task delay and energy; evidence level: simulation	Benefit depends on freshness and accuracy of the virtual state
Mou et al. (2025) [96]	Vehicle DTs migrated across edge nodes	Mobility-aware DT migration/replication	Edge servers, mobility management	Real mobility traces + simulation; compared with existing migration strategies	About 39% lower migration cost; evidence level: trace-driven simulation	Migration still requires prediction and control overhead
Fan et al. (2025) [97]	C-V2X/MEC state twin hosted at the edge	Robust reservation and offloading under imperfect DT prediction	C-V2X, MEC	Road-informed simulation; compared with non-robust/ idealized reservation baselines	Delay-sensitive service maintained under bounded error; evidence level: simulation	Uncertainty is bounded rather than fully distributional or OOD
Rosa et al. (2025) [98]	Edge-hosted CAV DT with peer and cloud interfaces	QoS-differentiated update interfaces among device, peer-twin, and cloud entities	CAV, edge/cloud, QoS-aware data distribution	Early real testbed; architecture validation rather than algorithmic baseline comparison	Implementability beyond pure simulation; evidence level: early testbed	Scale, mobility diversity, and multi-operator validation remain limited
Li et al. (2025) [99]	Vehicle-state DT updated from sensed dynamics	AoI-aware synchronization with Kalman estimation	V2X update scheduling, estimation	Analytical + numerical evaluation; compared with non-AoI update policies	Reduced estimation-error accumulation; evidence level: analysis + numerical evaluation	Closed-loop application impact is not evaluated
Tang et al. (2025) [100]	Vehicle/edge DT placement under limited edge resources	Joint timeliness-aware DT placement and resource allocation	ISAC, edge computing	Numerical optimization; compared with separated placement/allocation baselines	Freshness-resource tradeoff quantified; evidence level: numerical evaluation	Optimization complexity grows with network scale
Xing et al. (2026) [101]	Traffic-system DTs deployed at edge servers	Predicted-load-driven dynamic placement and reconfiguration	Edge servers, traffic-system orchestration	Numerical/ experimental evaluation; compared with static or less-adaptive placement	70.24% lower latency and 52.43% better resource matching; evidence level: numerical/ experimental	Prediction or placement errors can propagate into later decisions
Yang et al. (2026) [102]	Near-field vehicular DT at RSUs	Joint sensing, semantic communication, and computing updates	Near-field ISAC, semantic communication, edge computing	Simulation; compared with a benchmark ISAC scheme	20% higher transmission rate at maintained sensing accuracy; evidence level: simulation	Semantic-fidelity and cross-scenario validation remain open
Tang et al. (2026) [103]	Predictive IoV DT for edge offloading	Proactive migration and offloading from predicted trajectory/ connectivity	6G-enabled IoV, edge computing	OMNeT++ + DT engine; compared with reactive or conventional offloading baselines	Lower latency, energy, and task drops; evidence level: simulation/ emulation	Gains depend on prediction horizon and simulation assumptions

summarizes this comparison. The listed studies were chosen to cover the main architectural categories and evidence levels discussed in this survey, rather than simply the newest or most cited papers. The purpose is not to rank methods whose assumptions and baselines differ, but to identify which architectural choices are effective under which vehicular conditions and where the evidence remains incomplete.

4.1. Edge-Hosted Twins for Resource Orchestration

Early vehicular-DT studies primarily used the twin as a virtual state repository or prediction layer to support caching, offloading, and resource allocation. Examples include social-aware content caching [104], DT-driven offloading with intelligent reflecting surfaces [65], aerial-assisted resource allocation [105], and UAV-assisted resource orchestration [106,107]. These studies established an important architectural pattern: the physical vehicular network generates observations, an edge-hosted virtual model estimates or predicts network state, and an optimization or learning module returns resource decisions. Figure 10 abstracts this pattern into a mobility-aware placement view: as the vehicle changes its serving edge, the local twin or service state may remain at the current edge, migrate, be replicated, or coordinate with a global cloud twin. These choices trade physical–virtual proximity against transfer overhead, edge load, and state consistency.

Recent work makes the coupling between the twin and the resource controller more explicit. Jeremiah et al. jointly consider vehicle offloading, RSU association, and subchannel allocation in a DT-assisted VEC architecture [94]. Kong et al. use the virtual environment to support energy–delay-aware task offloading under vehicular dynamics [95]. Fan et al. further model imperfect DT prediction when reserving C-V2X communication and computing resources, which is important because a resource policy optimized for an inaccurate future state can lose the benefit of prediction [97]. Predictive frameworks in 2026 move one step further toward proactive operation by using future connectivity and resource estimates to trigger task migration/offloading before link degradation occurs [103].

The common finding is therefore conditional rather than universal: an edge-hosted DT can improve orchestration when the virtual state is sufficiently fresh and informative relative to the control timescale. The gain is reduced when the communication cost of maintaining the twin, edge queueing, prediction error, or mobility-induced migration delay becomes comparable to the task deadline. Consequently, the meaningful comparison is not “DT versus no DT” alone, but whether the added observation, prediction, and control loop produces a net reduction in end-to-end cost after twin-maintenance overhead is included.

4.2. Synchronization, Placement, and Migration Under Mobility

As illustrated in Figure 10, high mobility changes DT placement from a one-time deployment decision into a lifecycle problem. A twin that remains at the previous edge can incur increasing communication delay, whereas migration or replication introduces state-transfer traffic, interruption, and consistency requirements. Earlier work on secure DT migration in autonomous-driving edge systems already recognized that the virtual representation may need to move with the physical entity [108]. More recent studies explicitly optimize this process. Mou et al. formulate adaptive migration by jointly considering communication latency, migration latency, vehicle mobility, and changing edge states; experiments based on large-scale urban mobility traces report approximately 39% average improvement over the compared algorithms [96]. Lin et al. broaden the problem by considering DT model selection, building, synchronization, and migration latency when vehicles can be covered by heterogeneous BS and RSU infrastructure [109].

A second line of work treats synchronization itself as the optimization target. Li et al. model noisy vehicle-state evolution and connect estimation error with update timeliness through AoI-aware scheduling [99]. This is an important shift because it replaces the qualitative requirement of “real-time synchronization” with measurable staleness and estimation error. At a larger scale, Nereus predicts heterogeneous resource demand and dynamically places traffic-system twins across edge servers; the reported results show substantial reductions in communication latency and improved resource matching [101]. Rosa et al. complement simulation-dominated work with an edge data-distribution architecture that differentiates the QoS requirements of physical-device, peer-twin, and centralized-application interfaces and demonstrates an early real-testbed implementation [98].

Together, these studies indicate that twin placement, synchronization, and migration should not be treated as independent modules. A migration that reduces physical-to-twin distance may still be detrimental if model transfer interrupts updates; conversely, aggressive synchronization can overload the control plane and increase queueing. A more complete evaluation should therefore report at least synchronization delay or AoI, state/model error, migration interruption, migration traffic, edge load, and the application-level KPI before and after migration.

4.3. Learning-Enabled Twins: From Policy Optimization to Model Adaptation

Machine learning appears in vehicular-DT systems in several technically different roles. Reinforcement learning is often used as the decision engine for offloading, placement, caching, or migration, while the DT supplies state, simulated experience, or predictive features [65,81,110]. Transfer learning has been used to adapt a policy or model across changing vehicular environments [111]. Federated learning has been combined with DTs to train distributed models without centralizing all raw vehicle data [112]. Figure 11 illustrates a representative architecture in which RL uses DT-supported state information for online decision making, while FL coordinates distributed model training across vehicles or edge nodes without centralizing their raw data.

Recent work increasingly addresses the limitations of these learning paradigms rather than treating the algorithm name itself as the contribution. Zia et al. combine hierarchical federation with transfer learning to mitigate data heterogeneity and sparsity among vehicle groups, and evaluate the framework on real-world datasets [113]. Fan et al. explicitly account for uncertainty in DT-generated predictions rather than assuming a perfect virtual state [97]. These developments suggest that a useful learning-enabled DT should be evaluated through two coupled questions: whether the learning model improves the vehicular objective and whether the communication, synchronization, and retraining overhead required to maintain that model remains compatible with the application deadline. Figure 12 shows a complementary mobility-aware case in which model or policy knowledge is transferred between edge domains as the vehicle moves, with DT and communication data supporting adaptation at the target edge.

This distinction also prevents a conceptual ambiguity noted earlier in the survey. A DRL policy trained in a simulator is not by itself a DT. The DT contribution lies in the persistent physical–virtual update process and in how the resulting state, prediction, or simulated experience changes the online decision. Future comparative studies should therefore separate the gain from the learning algorithm from the gain attributable to the DT update/prediction layer.

4.4. Security and Trust for the Physical–Twin Data Path

Security-oriented vehicular-DT research has evolved from using blockchain as a generic immutability mechanism toward protecting specific interactions in the DT lifecycle. Earlier studies considered blockchain-assisted secure communication, resource sharing, data exchange, and trust management in vehicular DTs [114,115,116,117,118]. These approaches are relevant when multiple vehicles, edge providers, or administrative domains do not fully trust one another, but their applicability depends on transaction latency, consensus overhead, key-management complexity, and the freshness required by the application.

More recent work targets these requirements more explicitly. Wang et al. design a blockchain-assisted privacy-preserving and synchronized key-agreement mechanism for VDTNs, coupling entity/group management with secure real-time exchange [119]. This development illustrates a broader lesson: confidentiality and integrity are not sufficient if authentication, key establishment, or trust updates delay the physical–virtual loop beyond its validity window. Security evaluation should therefore report not only attack resistance but also additional signaling, computation time, storage, and the effect on synchronization freshness.

4.5. Communication- and Sensing-Aware Digital Twins

A growing set of studies uses the DT to model the communication environment itself rather than only the vehicle’s computing state. For example, DT-assisted programmable vehicular networks have been used to maintain QoS under dynamic blockage by exploiting a virtual representation of the propagation environment [120]. This direction becomes more important as vehicular systems adopt mmWave/near-field links and integrated sensing and communication, where channel state, geometry, and sensing accuracy directly affect the quality of the twin.

Tang et al. jointly study integrated sensing, communication-resource allocation, and DT placement, explicitly coupling sensing-information timeliness with limited edge resources [100]. Xue et al. further introduce environment-change detection and adaptive DT updating in an ISAC-assisted collaborative-offloading system [121]. For near-field vehicular links, Yang et al. jointly optimize sensing, computing, and semantic communication; their simulations report a 20% transmission-rate improvement while maintaining the sensing accuracy of the compared ISAC scheme [102]. These studies indicate that communication resources are no longer only a transport pipe for DT data: sensing accuracy, semantic extraction, beamforming, and DT update fidelity become coupled design variables.

The implication is that future vehicular-DT evaluation should expose the complete sensing–communication–computation path. A method that reduces transmitted bits through semantic compression, for example, should also quantify the resulting change in twin fidelity and downstream decision quality. Similarly, a sensing-rich DT that improves geometric awareness may increase computational and update overhead. Cross-layer benefit therefore depends on the operating point rather than on any single KPI.

4.6. Comparative Findings and Maturity of the Evidence

The comparison in Table 6 supports five conclusions. First, the twinned object is still heterogeneous: some studies twin vehicles or their states, others twin edge/network resources, and others twin a broader traffic environment. Conclusions should therefore not be transferred across these levels without checking their update and control timescales. Second, edge placement dominates the current literature because it reduces physical–virtual distance, but mobility makes placement, synchronization, and migration inseparable. Third, learning is mainly an orchestration mechanism; its benefit depends on the quality and freshness of the twin state and on the communication cost of maintaining or training the model. Fourth, explicit treatment of staleness, prediction error, security synchronization, and lifecycle management becomes more visible in 2025–2026 work, indicating a shift from idealized virtual replicas toward operational DT constraints [97,99,101,119].

Fifth, the evidence base remains heterogeneous. Most studies rely on numerical simulation with different mobility, channel, traffic, computing, and baseline assumptions, whereas real-testbed evidence remains comparatively limited [98]. Reported percentage gains in Table 6 are therefore not directly comparable across papers. A 30% latency reduction under one task-arrival model does not establish superiority over a 20% gain under another mobility/channel configuration. This lack of standardized scenarios, DT-update models, and common KPIs is itself an important finding from the surveyed literature and motivates the experimental-infrastructure and benchmarking discussion in the following sections.

5. Applications, Experimental Evidence, and Practical Deployment

The practical value of a vehicular DT depends on the application timescale, the object being twinned, and the strength of the available evidence. For this reason, applications should not be treated as interchangeable examples of a generic DT benefit. A traffic-management twin can tolerate aggregation and slower update cycles than a cooperative-driving twin, while a predictive-maintenance twin may prioritize calibration and long-horizon uncertainty over radio latency. This section therefore interprets applications using the requirement classes in Table 5 and distinguishes simulation evidence, trace-driven evaluation, early testbeds, and cross-domain methodological evidence.

5.1. Traffic Management and Cooperative Mobility

Traffic-level DTs combine observations from vehicles and infrastructure to maintain a virtual representation of road-network conditions and support prediction or control. CTwin-related work, for example, has explored continuous traffic emulation, situational awareness, and traffic-signal control using physical observations and virtual traffic models [122,123,124,125]. These studies illustrate a traffic-system twin in which the important state variables are not limited to one vehicle but include flows, queues, road conditions, and control actions distributed over a road network.

For communication-centric vehicular DTs, the more demanding case is cooperative or heterogeneous vehicle control. The DT-enabled edge-AI architecture in [6], for example, uses virtual risk/performance assessment to support heterogeneous vehicle automation levels. Such applications require the communication path and the control timescale to be reported together: a traffic estimate that remains useful for signal timing may be too stale for a safety-critical maneuver. Consequently, evidence for traffic-management effectiveness cannot be transferred directly to cooperative driving unless synchronization rate, state uncertainty, actuation authority, and failure handling are also compatible with the target application.

5.2. Fleet, Vehicle, and Predictive-Maintenance Services

Fleet-oriented DTs aggregate vehicle telemetry for monitoring, coordination, and lifecycle decisions. The connected-vehicle architecture in [126] is directly relevant because it treats vehicles as persistent fleet entities whose digital representations must coexist with dynamic communication. Compared with cooperative driving, fleet monitoring generally permits a longer control horizon, but it introduces other requirements: identity management, versioning, intermittent connectivity, multi-vehicle scalability, ownership of historical data, and reconciliation after disconnection.

Predictive maintenance is a related but technically different application because the twinned subject is often a vehicle component rather than the communication network. Vehicular examples include energy-storage and vehicle-health modeling [127], whereas several frequently cited DT maintenance demonstrations come from aircraft and industrial equipment [128,129,130]. In this survey these non-vehicular studies are treated only as methodological evidence for calibration, anomaly detection, prognostics, and lifecycle reasoning; they are not counted as direct evidence that the same performance will transfer to road vehicles. Their sensing rates, failure modes, mobility, communication availability, and safety constraints differ substantially from those of vehicular networks. This distinction addresses a broader problem in the literature: transferability should be argued through shared mechanisms rather than inferred from the common use of the term “digital twin.”

5.3. Communication-Network Optimization and Edge Orchestration

The most direct applications for the scope of this survey are DT-assisted communication and computing decisions. Recent studies use DT state or prediction for offloading, resource reservation, association, migration, sensing, and edge placement [94,95,96,97,100,101,103,109]. Their value is not merely that an optimization algorithm is executed in a virtual environment; the DT must provide a sufficiently fresh and informative state to change the physical-network decision.

Across these application families, the evidential status must be stated explicitly. Simulation-based percentage gains under different assumptions should not be interpreted as directly comparable deployment results; trace-driven studies and early testbeds provide stronger implementation evidence, but their scale and operating diversity remain limited.

5.4. Experimental Infrastructure, Datasets, and Reproducibility

Reproducible evaluation of vehicular DTs also requires the experimental infrastructure needed to reproduce and compare reported results. Existing studies combine tools from several communities rather than relying on a single standardized DT benchmark. SUMO provides microscopic road-traffic simulation [131]; Veins couples SUMO mobility with OMNeT++ network simulation for inter-vehicle communication [132]; CARLA provides a controllable urban driving and sensor environment [133]; and ns-3-based NR modules such as 5G-LENA support end-to-end radio/network evaluation [134]. Real mobility traces such as highD can replace purely synthetic trajectories [135], while multimodal datasets such as nuScenes provide camera, radar, lidar, and vehicle-context data for perception-related twin components [136]. For mmWave and massive-MIMO propagation learning, parameterized ray-tracing datasets such as DeepMIMO can support repeatable channel experiments, although they are not by themselves synchronized vehicular DT datasets [137].

A reproducible DT experiment must additionally specify the coupling among these layers. Reusing the same mobility trace is insufficient if one study updates the twin every 10 ms and another every 1 s, or if channel, computing, and model-update clocks are not aligned. At a minimum, benchmark reports should provide the physical sampling interval, communication-update process, computation/model-update delay, synchronization policy, twin-placement policy, initialization/calibration method, failure/disconnection handling, and application deadline. The field currently lacks a widely accepted benchmark that jointly fixes these elements, which explains why many reported gains cannot be compared quantitatively across studies.

5.5. Industrial Considerations and Practical Implications

For industry, a useful deployment strategy is incremental rather than “full twin first.” The appropriate first target is an application for which the required physical data already exist and for which a stale or failed twin cannot directly create an unsafe actuation. Fleet monitoring, network observability, predictive diagnostics, and advisory optimization are therefore easier entry points than safety-critical closed-loop driving. After the physical–virtual data path is validated, additional prediction or control functions can be introduced with explicit acceptance criteria.

A deployment decision should be made against four practical questions. First, what must be twinned? Modeling every available vehicle variable increases data, model, storage, and validation cost without necessarily improving the target service. Second, where should the twin run? On-board, roadside-edge, operator-edge, and cloud placement trade communication delay against compute capacity, migration frequency, ownership, and cost. Third, how fresh and accurate must it be? Update frequency should be derived from the application deadline and state dynamics rather than set to the maximum supported telemetry rate. Fourth, what happens when the twin is wrong or unavailable? Operational designs require health monitoring, confidence/validity checks, degraded modes, rollback or human override where applicable, and separation between advisory and safety-critical actions.

Industrial reports should therefore disclose more than application-level KPI gains. Useful deployment evidence includes the number and type of vehicles, RSUs, and edge servers, telemetry and model-transfer traffic, backhaul requirement, compute and storage footprint, energy consumption, availability, update violations, maintenance burden, software/model versioning, operator boundaries, and capital/operating assumptions. These quantities determine whether a DT architecture can scale beyond a prototype. They also make it possible to distinguish a technically feasible DT from an economically and operationally sustainable one.

6. Evidence-Driven Research Agenda

Based on the recurring limitations identified in Section 3, Section 4 and Section 5, the research agenda is organized around gaps in freshness, uncertainty, placement, reproducibility, interoperability, lifecycle consistency, and deployment evidence. The priorities are grouped by research horizon, with immediately testable engineering questions separated from longer-term architectural issues.

6.1. Near-Term Priority: Freshness, Validity, and Safe Use

The most immediate research need is to make “real-time” and “high-fidelity” operationally testable. AoI-aware synchronization [99] and robust use of imperfect DT predictions [97] are important steps, but application-level validity requires linking staleness and uncertainty to the consequence of a decision. The relevant threshold is therefore not a universal update period. It is the region of state age and model error within which a specific action remains acceptable. This should be measured under variable load, retransmissions, handovers, sensor faults, and computation delays rather than under a constant-latency abstraction.

For safety-related applications, the twin also needs an explicit authority model. A low-confidence or stale twin may remain useful for advisory visualization while being unacceptable for automatic actuation. Research should therefore define confidence-aware abstention, degraded operating modes, rollback/recovery, human override where relevant, and fail-safe or fail-operational behavior. These mechanisms should be tested together with cybersecurity because a fresh but compromised state and an authentic but stale state can both make the physical–twin loop unsafe.

6.2. Near- to Medium-Term Priority: Placement, Adaptive Fidelity, and Resource Coupling

Mobility makes twin placement a dynamic systems problem. Existing migration/placement work demonstrates the possibility of reducing cost through proactive movement of virtual state [96,101,109], but future work should compare migration, replication, remote execution, and split-twin designs under the same mobility and edge-load traces. The evaluation should include not only average latency but also service interruption, transferred model/state size, consistency, energy, and failure recovery.

A related direction is service-adaptive fidelity. Cooperative driving, fleet monitoring, maintenance, and network optimization do not require the same variables or update rates. A twin should therefore be able to change model complexity, synchronized state subset, prediction horizon, and placement according to service criticality and available communication/computing resources. The objective is not simply a “lighter twin”; it is to preserve the information needed by the downstream decision while avoiding state, computation, and model detail that does not improve that decision. Such work should report fidelity–freshness–resource Pareto fronts instead of a single weighted objective whenever possible.

6.3. Medium-Term Priority: Reproducibility, Lifecycle, and Interoperability

The lack of common experimental definitions currently prevents robust cross-paper comparison. A useful community benchmark should combine at least one realistic mobility trace, a disclosed V2X/channel model, a computing model, an explicit twin-update process, and application-level deadlines. Simulator configurations, data splits, random seeds, model versions, and update schedules should be published whenever possible. More importantly, the benchmark must define how the physical and virtual timelines are coupled; otherwise identical network simulators can produce fundamentally different DT freshness.

Vehicular DT lifecycle management is another medium-term need. A twin can be instantiated by one administrative domain, migrated through another edge infrastructure, updated concurrently by multiple data sources, and later reconciled after disconnection. Research should formalize authoritative state, versioning, replication, conflict resolution, authentication, handover semantics, and retirement. Recent DT/DTN standards provide useful concepts and interfaces [30,31,34], but a vehicular interoperability profile that maps these functions onto V2X data, mobility, operator boundaries, and safety requirements remains to be established.

6.4. Long-Term Priority: Hierarchical and 6G-Native Vehicular Twins

Longer-term work can address hierarchical twins that connect component, vehicle, network, fleet, and city scales. Such systems should not assume that every level shares the same state, owner, update frequency, or control authority. The research problem is to determine what information is aggregated upward, what constraints or decisions propagate downward, and how errors or failures at one level affect another. Multi-timescale consistency and scalable validation are more important here than simply increasing the geometric or visual detail of a city model.

6G-oriented sensing, near-field communication, semantic communication, and AI-native network functions may provide useful capabilities for these hierarchical twins, but they should be judged by their effect on twin validity and decision quality rather than by link KPI improvements alone. Recent ISAC- and semantic-communication-oriented studies already expose this coupling [100,102,121]. A 6G-native DT research program should therefore quantify how sensing accuracy, channel prediction, semantic distortion, communication latency, computation cost, and state freshness jointly influence the physical-system task.

6.5. Governance, Ethics, and Accountability as Research Requirements

Ethical and governance questions are inseparable from the technical lifecycle of a vehicular DT because persistent twins can combine location, driving behavior, infrastructure observations, and inferred vehicle/user states. Research should specify who is allowed to instantiate, read, modify, migrate, or retire a twin; which party owns raw and derived data; how consent and purpose limitation are represented; and how provenance is preserved across model updates and administrative domains [138,139].

Accountability is also necessary when twin-assisted decisions affect people or shared infrastructure. Bias or missing observations can change traffic-control recommendations, while opaque model updates can make it difficult to determine why a decision was made. Auditable data/model versions, provenance, logging, explainability appropriate to the decision context, and mechanisms to challenge or override erroneous decisions are therefore practical research requirements rather than optional ethical add-ons. Regulatory compliance such as GDPR provides part of the governance context, but technical designs must translate these principles into data retention, access control, federated ownership, and verifiable decision records [140].

7. Conclusions

This survey examines digital twins through the specific lens of vehicular communications. The scope adopted in this survey distinguishes persistent, observation-updated twins from static digital models and separates component, vehicle, communication-network, fleet/traffic, and city-scale twins. This distinction is necessary because communication paths, synchronization rates, validation targets, ownership arrangements, and decision authority differ substantially across these classes.

The reviewed literature reports potential benefits in network optimization, traffic management, cooperative mobility, monitoring, and maintenance, but the evidence is heterogeneous. Most communication-centric results are simulation or trace driven, while early testbed work remains limited in scale. Reported percentage gains therefore cannot be compared without accounting for mobility, channel, traffic, computation, prediction, baseline, and twin-update assumptions. Non-vehicular predictive-maintenance studies can provide transferable methods, but they should not be treated as direct evidence for road-vehicle deployment unless their sensing, timing, communication, and safety assumptions are shown to transfer.

A rigorous vehicular-DT evaluation should jointly report state freshness, communication reliability, model fidelity and uncertainty, computation/update latency, migration and synchronization overhead, lifecycle consistency, security, functional safety, and infrastructure cost. Reproducibility further requires disclosure of the coupling among mobility, channel/network, computing, and twin-update timelines. Common traffic, network, driving, mobility-trace, and channel resources can support such experiments, but the field still lacks a broadly accepted end-to-end DT benchmark that fixes these interactions.

The practical research priority is therefore not simply to create more detailed virtual replicas. Near-term work should determine when a twin is sufficiently fresh, valid, and safe to influence a physical vehicular system; medium-term work should address adaptive fidelity, placement, reproducibility, lifecycle, and interoperability; and longer-term work should investigate hierarchical and 6G-native twins across multiple spatial and temporal scales. Progress should be judged by measurable application-level evidence and deployment feasibility rather than by the presence of a particular enabling technology. This evidence-driven perspective provides a basis for deciding when a DT is technically justified, how it should be evaluated, and what remains necessary before communication-coupled vehicular twins can be trusted at scale.