Dynamic Relay Assignment Scheme for Efficient V2V Content Precaching in Content-Centric Internet of Vehicles

Abstract

The rapidly growing data demands of autonomous driving and onboard multimedia services pose significant challenges to traditional roadside unit (RSU) based content delivery, particularly under limited cache capacity and coverage gaps. In the content-centric Internet of Vehicles (CIoV), vehicle-to-vehicle (V2V) precaching has emerged as an effective solution to mitigate these limitations. However, existing schemes rely on static precaching roles, leading to inefficiencies when a precaching vehicle initiates its own content request. To address this issue, we propose a dynamic relay assignment scheme (DRAS) that enables seamless role transitions without discarding cached data. Upon detecting such a role-transition event, the RSU assigns two new precaching vehicles to independently serve the original requester vehicle and the newly transitioned requester vehicle, ensuring continuous service. Furthermore, we extend this to an energy-efficient DRAS (EE-DRAS) that incorporates vehicle-to-infrastructure (V2I) and V2V transmission energy costs into the selection process, achieving a balanced trade-off between energy consumption and delivery efficiency. Extensive NS-3 simulations show that DRAS reduces average delay by up to 53% and improves throughput by 8% over existing baselines. EE-DRAS further reduces energy consumption by up to 66% while maintaining service fairness.

1. Introduction

The accelerating development of autonomous driving technologies and the widespread adoption of in-vehicle infotainment systems have transformed modern vehicles into mobile computing platforms with increasing data requirements [1]. These changes have resulted in a noticeable increase in not only the volume of data requests, but also the size of each request [2]. The traditional architecture of modern networking technologies is characterized by a reliance on centralized content servers and fixed RSUs to deliver content to users [3]. This reliance is challenged by limited cache storage and finite radio bandwidth, which hinder the effective response to evolving technical requirements. As the number of devices competing for these resources increases, the resultant spike in contention gives rise to packet loss, prolonged buffering, and poor QoE. In safety-critical scenarios, such as real-time collision warnings or dynamic lane change notifications, network bottlenecks have the potential to directly compromise passenger safety [4].

In order to address the fundamental mismatch between the enormous demand for content and the limited delivery infrastructure, researchers are turning to content-centric networking (CCN) and adapting its principles for use in the automotive domain in a CIoV paradigm [5]. In CIoV, each piece of data is identified by name rather than server IP, enabling requests to be directed to the closest copy in the RSU cache, onboard storage in a neighboring vehicle, or the original content server [6]. This reduces redundant backbone fetches and balances load across the network. When a vehicle is briefly disconnected from the serving RSU, it is able to switch to an alternate cache source without having to make a round-trip back to the origin server. This mitigates intermittent connectivity issues. This flexibility is advantageous in highly dynamic IoV environments, where node density and link quality fluctuate rapidly due to vehicle mobility and varying road conditions [7].

Precaching has emerged as a powerful technique to further reduce perceived latency by positioning content on RSUs along a vehicle’s predicted route [8]. However, from an economic perspective, the universal implementation of RSUs across all geographies is considered impractical. Consequently, there are inevitable coverage gaps, known as outage zones, where vehicles are unable to access cached RSU content [9]. The solution to this problem is facilitated by V2V precaching schemes, which enable peer vehicles that have already downloaded or precached content to be utilized as mobile caches [10,11,12,13]. These vehicles function as relays, transmitting data to the requester upon entering communication range. While V2V precaching extends service continuity beyond the RSU coverage, most existing solutions assume that once a vehicle is selected as a precaching vehicle, it is dedicated to that relay role. In fact, the precaching vehicle itself may become a new content requester during its precaching mission, which may result in the discarding of previously precached chunks or a delay in the new request until precaching is completed. These options inevitably result in inefficient use of resources and a degradation of the quality of service.

Therefore, we propose a DRAS, an approach that addresses the limitations of existing methods. This scheme directly addresses the inherent unfairness wherein a selected precaching vehicle is prevented from initiating its own content request. To overcome this issue, DRAS introduces a novel role transition framework that guarantees content request rights for all vehicles. Unlike conventional studies that never consider this scenario and permanently lock a vehicle into a relay role, DRAS allows the precaching vehicle to transition into a requester vehicle while preserving and delivering its already cached chunks to the original requester. Simultaneously, the RSU dynamically assigns two new precaching vehicles: one to replenish the remaining deficit of the original requester vehicle, and another to exclusively serve the newly designated requester vehicle. The analytical expressions derived herein evaluate the dwell time of each candidate within RSU coverage, the expected connectivity window with the requester, and the maximum precaching capacity. These metrics are combined into a min max selection criterion that guarantees maximal utilization of available bandwidth while maintaining seamless delivery without traffic waste.

Beyond latency and throughput, energy efficiency has emerged as a critical requirement for sustainable vehicular networks [14,15]. Frequent RSU to vehicle precaching and vehicle to vehicle relaying incur significant power consumption for both infrastructure and vehicles, especially for electric or hybrid platforms with limited battery capacities. Suboptimal relay selection can trigger redundant transmissions and prolonged link activations, amplifying cumulative energy usage and ultimately constraining the scalability and sustainability of CIoV systems.

To address the emerging energy constraints of battery limited autonomous vehicles, we further extend DRAS into an EE-DRAS. While DRAS effectively maximizes throughput and ensures service continuity, it does not account for the substantial power consumed by frequent V2I precaching and V2V relaying. EE-DRAS solves this issue by incorporating transmission energy expenditure into the relay vehicle selection. Specifically, EE-DRAS augments the optimization objective with energy cost terms for both V2I precaching (RSU $\to V_i$) and V2V relaying ($V_i\to V_{\mathrm{req}}$), enabling the RSU to jointly consider bandwidth utilization, connectivity duration, and per bit transmission energy. This design achieves a balanced tradeoff between delivery efficiency and power consumption while preserving continuous service and fairness among vehicles. We conducted NS-3 based simulations to validate the effectiveness of both schemes. The empirical results demonstrate that DRAS improves the total content download size and service fairness, outperforming the latest vehicle to vehicle precaching scheme named MPVS [13]. Furthermore, EE-DRAS maintains the latency and throughput gains of DRAS while reducing energy consumption.

The rest of this paper is organized as follows. Section 2 reviews related studies on CIoV precaching, V2V relaying, and energy-aware caching/offloading. Section 3 presents the system model and provides an overview of the proposed DRAS and EE-DRAS frameworks. Section 4 details the DRAS design, including role-transition detection and the dual relay re-selection mechanism for service continuity. Section 5 then describes the EE-DRAS extension by incorporating the energy costs of V2I/V2V into the selection and allocation process of the sections precaching vehicle. Section 6 evaluates both schemes through extensive NS-3 simulations under diverse mobility, density, and content demand scenarios. Finally, Section 7 concludes the paper.

2. Related Works

2.1. Content-Centric Internet of Vehicles

In vehicular networks, traditional IP-based networks have problems because vehicles move continuously and topology frequently disconnects. The IP-based networks require connecting the sender and receiver to start a communication, but the vehicle connection is easily lost by tunnel entrances and intersections. Since the vehicle must be assigned an IP address and set a route whenever it disconnects from an RSU, the communication is inefficient, and delays occur. In addition, IP addresses change continuously as the vehicle moves, which disrupts the connectivity of networks. As a result, IP-based networks are not suitable for autonomous driving or V2X environments where real-time information is important.

To solve IP-based networks problems in vehicular networks, researchers start looking into CCNs [7,16,17]. CCNs require data based on content name instead of IP addresses, and the nearest vehicle or RSU that has stored information transmits the data. Furthermore, RSUs and vehicles can cache content, and they deliver cached data immediately when the other users request same information. Therefore, CCNs have a strong structure for mobility and disconnection. Since data can be received from nearby nodes even if the vehicle disconnect temporarily while the vehicles moving, CCNs improve the stability of IoV communication. Thus, a CIoV paradigm was introduced by turning CCN and adapting its principles for use in the automotive domain in IoV [5].

2.2. Mobility-Based Precaching

Content service in the CIoV is fundamentally constrained by the finite storage capacity of RSUs. Because an RSU cannot cache all available content, vehicles may request items that are absent from the local RSU cache, which forces retrieval from remote sources and increases access delay as well as backhaul traffic. To mitigate these limitations, researchers have actively investigated precaching mechanisms. Precaching proactively stores content on the RSU before the vehicle enters the coverage area. Then, the RSU immediately provides the content when the vehicle enters the coverage area. In CIoV, this proactive placement reduces perceived latency and improves service continuity, especially in scenarios with short RSU contact times and intermittent connectivity. Accordingly, a wide range of mobility-aware precaching approaches has been proposed, leveraging vehicle trajectory prediction, contact opportunities, and spatiotemporal demand patterns to determine what content to cache and where to place it in advance.

Khelifi et al. [18] proposed a PCMP method that uses a long short-term memory (LSTM) module to predict the next RSU visited by a vehicle and calculates the exact number of content chapters to be precached, taking into account factors such as vehicle speed, path within RSU coverage, connection time, and link bandwidth. Liu et al. [19] introduced a utility function based on user mobility probability and video popularity, and proposed a new preloading and caching strategy that increases cache hit rates and ensures the stability of video services during cell transitions through an integrated cache replacement strategy that takes resource costs into account. Park et al. [20] proposed a technique to improve caching efficiency by predicting vehicle movement paths using Markov models and distributing content to multiple candidate RSUs in advance according to the probability of those paths. Zhe et al. [21] proposed a hierarchical precaching method that predicts future demand by considering both user preferences and past popularity of videos through non-negative matrix factorization (NMF), and calculates the number of video fragments to cache based on the speed vector of the vehicle. Ikram et al. [22] introduced an LRF cache strategy that stores data requested by vehicles in the next relay node to solve node mobility issues and improve cache efficiency in an ICN-based IoV environment. Feng et al. [23] designed a hierarchical cooperative caching framework that predicts mobility and content popularity based on past vehicle movement paths and user request data, thereby increasing cache hit rates and minimizing average latency. Nam et al. [5] presented a content storage management and precaching framework called CSMP for CIoV that reduces delay and backhaul traffic under limited RSU cache capacity. It prioritizes important content to avoid harmful evictions and uses an ILP-based precaching strategy that selects suitable RSUs and caches only missing portions within tolerable delay. It improved cache hit ratio while reducing download latency.

However, these V2I precaching methods still have limitations. Achieving full network coverage with RSUs is impractical due to the cost of deploying RSUs. Areas not covered by RSUs are called outage zones. In outage zones, requester vehicles must consume high-cost wireless resources from the BS or experience delay because they cannot receive the requested content.

To cover outage zones, many researchers have studied precaching schemes that utilize other vehicles to provide requested content through V2V communication in service interruption areas within CCN-IoV. Vehicles that provide content through precaching are called precaching vehicles. Guo et al. [24] proposed a scheme that combines precaching and a carry-and-forward scheme. Relay vehicles precache data from RSUs and then carry and deliver it to requester vehicles in coverage holes, thereby extending the access time to RSUs and minimizing the dark areas. Wang et al. [10] proposed a scheme to reduce the out-of-edge area by sequentially delivering content. They select two precaching vehicles, one traveling in the same direction as the requester vehicle and another coming from the opposite direction, to avoid overlapping delivery periods. Ahmed et al. [12] proposed a scheme to effectively cover the content delivery requirements of the out-of-edge area by calculating the delivery capacity of each candidate vehicle and selecting multiple same-direction vehicles with the highest capacity. Nam et al. [13] proposed a Multiple Precaching Vehicle Selection (MPVS) scheme that ranks vehicle groups to select the optimal precaching group. The scheme ensures fairness by distributing the precaching load equitably among the vehicles, allowing them to also request their own content.

However, existing V2V precaching schemes often exhibit an inherent unfairness: once a vehicle is selected as a precaching relay, it is typically prevented from initiating its own content requests. If such a relay discards previously precached chunks to become a requester, the network incurs substantial traffic waste and the service quality for ongoing requester sessions degrades. To address this limitation, we propose DRAS that enables a precaching vehicle to initiate its own request while still preserving and forwarding the already precached content to requester vehicles in outage zones, thereby maintaining service continuity without resource waste.

2.3. Energy-Efficient Precaching

The increasing data demands of safety and infotainment services have made precaching essential for reducing latency and sustaining service continuity in dynamic vehicular networks; however, frequent V2I precaching and V2V relaying can incur substantial cumulative energy consumption due to repeated transmissions and unstable connectivity, particularly in dense traffic and outage zones. Energy-efficient precaching is, therefore, critical for sustainable CIoV deployments, as it lowers the operational burden on both vehicles (e.g., battery-limited EVs) and infrastructure while avoiding decisions that yield marginal delay gains at excessive energy cost. Accordingly, energy-aware precaching should jointly account for mobility-driven contact opportunities (RSU dwell time and V2V connectivity duration), caching/precaching capacity constraints, and link-/node-specific energy costs and budgets to balance delivery performance and service continuity against power expenditure. Accordingly, a variety of energy-efficient precaching approaches have been proposed to explicitly incorporate energy consumption into caching, relay selection, and content delivery decisions. Zhang et al. [25] proposed an ICN-based mobility-aware caching scheme modeled by a 2-D Markov process. They formulate energy-efficiency-oriented fractional optimization and derive an online policy via Lyapunov methods, improving hit ratio/utilization while reducing energy. Wu et al. [26] proposed OEECS for ICVs under mixed V2V/V2R connectivity by modeling transmission/computing energy and casting cache-node selection as an optimal stopping problem. Energy-weighted, proximity-based replication reduces energy and access delay under mobility/popularity awareness and energy budgets. Zeng et al. [27] proposed an SDN-based VEC framework that clusters edge servers and partitions storage into self/group/global tiers to reduce supporting-data acquisition and migration delay. It can incorporate energy efficiency by limiting edge–cloud transfers and adopting energy-aware replacement and DRL-based joint offloading–caching. Gupta et al. [28] proposed an ICN-based caching scheme using in-network caching and name-based routing with popularity/mobility-aware cooperation among vehicles/RSUs to improve hit ratio and reduce delay. Energy savings can be enhanced via short-hop reuse, edge-side replication, and energy-weighted replacement with optional learning-based trade-offs. Hu et al. [29] proposed an AoI-driven energy-efficient caching and offloading scheme for UAV-assisted VANETs, solved online with DDPG and differentiated replay. Route-aware cache refreshing and AoI-based offloading with energy budgets reduce energy while maintaining timely updates. Elgendy et al. [30] proposed an energy-efficient multi-tier VECC framework that jointly optimizes task caching and offloading by minimizing energy under latency QoS and resource constraints. RSU task caching and adaptive offloading reduce backhaul and total energy without harming timeliness. Liang et al. [31] proposed an energy-efficient cooperative caching framework for urban IoV systems by leveraging fixed route buses as mobile RSUs.By jointly optimizing task decomposition, multi-source caching, and energy management, the proposed scheme reduces content delivery delay and overall system energy consumption.

Despite these advances, most existing studies emphasize energy-efficient cache placement or offloading, yet they do not handle relay role transitions in V2V precaching, where a selected relay becomes a requester. Moreover, V2I precaching and V2V delivery are often optimized separately, while outage-zone continuity through chunk preservation/handover and fairness-aware relay assignment is insufficiently addressed. To fill these gaps, we propose EE-DRAS, which detects relay-to-requester transitions, preserves cached chunks to sustain the original requester, and performs dual relay re-selection to concurrently support both the original and new requesters. EE-DRAS jointly incorporates link-/node-specific energy costs for RSU → vehicle precaching and vehicle → vehicle forwarding with mobility-dependent dwell/connectivity and capacity constraints, enabling an energy-aware and fair trade-off among throughput, delay, and energy in outage zones.

Table 1 summarizes the key characteristics of existing V2X precaching schemes in comparison to our proposed method. The table categorizes the literature based on essential criteria. C1 (Outage zone support) evaluates whether content provision services can be maintained outside the communication range of RSUs. C2 (Dynamic Role Transition) examines whether the system accommodates scenarios in which a vehicle, initially designated as a precaching node, subsequently transitions into a requester vehicle. Lastly, C3 (Energy-Awareness) assesses whether energy consumption is factored into the content provisioning process. Regarding C1, a partial support designation (e.g., denoted as Δ) indicates that content delivery within an outage zone is not deterministically guaranteed. Instead, content may be delivered opportunistically via V2V caching; a requester vehicle can receive the requested data only if it opportunistically encounters another vehicle that has already cached the corresponding content. As shown in the summary, while several studies address mobility-aware routing and load balancing, the proposed EE-DRAS integrates dynamic role transition and energy-efficient transmission into the assignment process to ensure service continuity within outage zones.

Table 1. Comparison of Related Works in CIoV Precaching.

Ref.	Category	C1	C2	C3	Key Details & Limitations
[18]	V2I Precaching	X	X	X	LSTM-based next RSU prediction. Limited to RSU coverage.
[19]		X	X	X	Utility function via mobility and popularity. Cannot cover outage zones.
[20]		X	X	X	Markov model-based path prediction. Cannot cover outage zones.
[21]		X	X	X	NMF for popularity and speed vector. Cannot cover outage zones.
[5]		X	X	X	CSMP (ILP-based). Minimizes delay but restricted to RSU area.
[24]	V2V Precaching	O	X	X	Carry-and-forward. Disregards relay vehicle’s own requests.
[10]		O	X	X	Dual-direction relay. Cannot handle relay’s role transitions.
[12]		O	X	X	Multiple same-direction vehicles. Ignores dynamic transitions.
[13]		O	X	X	MPVS (Grouped nodes). Lacks relay role transition handling.
[25]	Energy-efficien Precaching	Δ	X	O	Lyapunov optimization caching. No V2V relay transition handled.
[26]		Δ	X	O	OEECS (Optimal stopping). Focuses on energy, lacks transition.
[28]		X	X	O	Energy-weighted replication. Separate from V2V relay processing.
[31]		O	X	O	Buses as mobile RSUs. No handover for transitioning relays.
Proposed	EE-DRAS	O	O	O	Dual relay re-selection with chunk preservation and energy optimization.

3. Network Model and Scheme Overview

This section describes the network architecture and the operational flow of the proposed dynamic relay assignment scheme. Section 3.1 defines the network model, including the V2I and V2V communication environments, as well as the roles of the RSUs, vehicular nodes, and content structures. Section 3.2 outlines the overall scheme, providing a step-by-step procedure to ensure seamless service continuity during relay role transitions.

3.1. Network Model

In this study, we adopt the network illustrated in Figure 1 as the reference model for the proposed C-IoV scheme. The network consists of vehicles traveling along roads and RSUs deployed at regular intervals (e.g., intersections), which are connected to a central content server via high-speed wired backhaul links. Vehicles move toward random destinations by following the shortest path established via in-vehicle navigation systems. RSUs provide communication coverage over designated road segments via V2I links, while V2V wireless communication enables direct interaction among vehicles. To facilitate dynamic precaching and relay selection, all nodes communicate using IEEE 802.11p-based WAVE [32]. Each vehicle periodically broadcasts a beacon message every 1 s containing its real-time mobility information—including its location, speed, and predefined path route to its associated RSU. RSUs collect these beacons to maintain an updated, real-time mobility tracking table for all vehicles within their coverage area. Due to geographical and deployment constraints, deploying RSUs to achieve full contiguous coverage is impractical. This results in outage zones between adjacent RSUs where V2I connectivity is unavailable. When a vehicle requests content within an RSU coverage area, it encapsulates its real-time state (location, speed, direction) and the requested content size within the request packet. Upon receiving this request, the RSU retrieves the content from the content server and evaluates whether the data can be fully delivered before the vehicle exits the coverage range. If the content is too large, the RSU leverages the requester’s attached information alongside the holistic mobility data stored in its table to compute an optimal selection. Specifically, the RSU calculates and selects optimal precaching vehicles to store the remaining content in advance. These selected vehicles subsequently deliver the precached data to the requester via V2V communication while traversing the outage zone. This coordinated calculation and relaying procedure ensures continuous content delivery and effectively minimizes the delay caused by outage zones.

Figure 1. Basic V2V precaching. The dashed yellow lines separate the lanes for traffic moving in the same direction.

3.2. Scheme Overview

If a vehicle wants to download content while moving, it creates an interest packet, and when the vehicle enters the RSU coverage area, it transmits the interest packet for the content to the RSU. We refer to this vehicle as the requester vehicle. When the RSU receives the interest packet, it checks whether the content is in its caching storage. If the content is not available, the RSU requests the content from the content server or another RSU that has the content, downloads and stores it. Next, the RSU checks whether there is sufficient time to provide the content to the requester vehicle and determines the necessity of precaching the content by other vehicles in the outage zone. To calculate the necessity of precaching, the RSU compares the size of the requested content with the downloadable size for the requester vehicle within the RSU coverage area. The downloadable size is calculated based on WAVE communication, taking into account the remaining travel time within the coverage area and the RSU’s transmission speed. If the downloadable size is larger than the requested content size, the RSU can download all content to the requester vehicle, so precaching is not necessary. On the other hand, if the downloadable size is smaller than the requested content size, the requester vehicle cannot download all the content within the RSU coverage area. In this case, vehicles must be selected to deliver the precached content in the outage zone. When selecting vehicles for precaching, the RSU considers the dwell time of the precaching vehicle candidates within the RSU coverage area and the expected connection time with the requester vehicle in the outage zone.

However, unlike the existing precaching schemes that assume fixed relay roles, our scheme DRAS considers the critical issue where a vehicle selected as a precaching vehicle becomes a requester vehicle. Traditionally, if this precaching vehicle discards the precached data to act as a requester vehicle, it causes traffic waste and degrades the communication service quality of the existing requester vehicle. Thus, DRAS proposes a solution where the precaching vehicle does not discard the data but instead transmits the preserved data from the outage zone to the existing requester vehicle, maintaining continuous service delivery. A vehicle that transitions from a precaching vehicle to a requester vehicle is referred to as a Dynamic Assignment (DA) vehicle. The continuous operation of this transitioning process is step-wise illustrated in Figure 2. Arrows indicate the delivery of precached chunks, while matching colors are used to represent the transfer of each chunk’s specific color. First, as shown in Figure 2a, a vehicle previously selected as a precaching relay enters an RSU coverage area indicated by dashed lines and transmits a new interest packet to request its own content. The RSU must first ensure that the original requester’s service is maintained despite this transition. Subsequently, in Figure 2b, rather than dropping its relay duties, this DA vehicle preserves the already-cached chunks and continues to deliver them to the original requester as they traverse the outage zone. Finally, to fully assist this role switch without chunk discarding, the RSU triggers the assignment of two new relays as depicted in Figure 2c. If there are multiple candidate vehicles, the RSU dynamically assigns one optimal precaching vehicle to sustain the remaining delivery for the original requester, and an additional precaching vehicle specifically to serve the new DA vehicle. This simultaneous assignment guarantees seamless service for both vehicles.

Figure 2. Dynamic assignment vehicle operation process: (a) precaching vehicle requests content within the RSU coverage area; (b) content delivery in the outage zone, with the DA vehicle acting as a precaching vehicle; (c) content delivery to the original requester vehicle and the DA vehicle from their respective precaching vehicles in the outage zone.

If there is no vehicle that can be selected as a precaching vehicle instead of the DA vehicle for the existing requester vehicle, the DA vehicle must temporarily maintain its current role. Additionally, since the DA vehicle has become the requester vehicle, the RSU must determine whether this vehicle also requires precaching. We describe the proposed DRAS scheme in detail in Section 4.

To consider the energy efficiency of vehicles, our scheme EE-DRAS extends DRAS by additionally considering the energy expenditure of both V2I precaching and V2V delivery. If a precaching vehicle becomes a requester, EE-DRAS preserves the already precached chunks and continues to deliver them to the original requester in the outage zone, while selecting new relays with an energy-aware objective that balances delivery efficiency and power consumption. A vehicle that transitions from a precaching role to a requester role remains a DA vehicle; upon switching, it sends an interest packet to the RSU, and the RSU must first ensure the original requester service continuity and respect node-level energy budgets. If no feasible substitute relay exists for the original requester, the DA vehicle must temporarily maintain its precaching role; otherwise, EE-DRAS simultaneously assigns new relays—one to sustain the original requester and another to support the new requester—by optimizing a metric that integrates bandwidth utility, link stability, and per-bit transmission energy. Additionally, since the DA vehicle is now a requester, the RSU determines whether it also requires precaching under the energy-aware objective and enforces coupling between V2I precaching volume and subsequent V2V delivery chunk deficit compensation. We describe the proposed EE-DRAS scheme in detail in Section 5.

4. Dynamic Relay Assignment Scheme

In this section, we propose our scheme DRAS for selecting a precaching vehicle that ensures continuous content transmission to vehicles in the outage zone. To achieve efficient content transmission, the scheme selects a vehicle with excellent connectivity to the requesting vehicle as the precaching vehicle. When the precaching vehicle is changed into a new requesting vehicle, the scheme dynamically updates by selecting both a new precaching vehicle for the original requester and a new precaching vehicle for the new requester. The network model for our scheme involves periodic beacon message exchanges between vehicles and RSUs. When a vehicle enters the communication range of an RSU, it transmits a beacon message containing its location, speed, and path information. The RSU stores this data in its vehicle information table, allowing it to track the vehicles within its communication range. All RSUs are connected to the content server through the Internet via a wired backbone link, and wireless communication between RSUs and vehicles is handled using the WAVE protocol. Section 4.1 elaborates on the process for determining the need to select a precaching vehicle when a vehicle requests content, especially in the outage zone, and describes the method for selecting the appropriate precaching vehicle. Section 4.1.1 addresses the scenario in which a precaching vehicle becomes a requesting vehicle, outlining the solution for handling this situation and ensuring the continuity of content delivery.

4.1. Relaying Vehicle Selection

When a vehicle initiates a content request, a REQ packet is dispatched via WAVE upon entry into the radio range of a proximate RSU. The REQ packet contains the requested content ID, the requested chunk number, and the requester vehicle ID. In the event that this constitutes the initial request for the content, the requested chunk number will be set to zero. Otherwise, the sequence number of the next required chunk is specified in the packet. In the event that the vehicle remains outside the range of the RSU, it will await the request and attempt retransmission until it enters the RSU’s range. Upon receipt of the REQ packet, the RSU verifies the existence of the requested content ID in its caching storage (CS). If a positive identification is made, the RSU transmits the content immediately to minimize delay. Conversely, in the absence of content in the CS, the request is recorded in the Pending Interest Table (PIT) in accordance with the CCN protocol. The Forwarding Information Base (FIB) is then referenced to obtain the content from the Content Server or neighboring RSUs, after which it is forwarded to the requesting vehicle. The Table 2 s the summary of all symbols in Section 4.

Table 2. Notation Summary for Section 4.

Symbol	Description
$C_{\mathrm{rest}}$	Remaining size of the requested content
$N_{\mathrm{total}},N_{\mathrm{delivered}}$	Total number of chunks and the number of chunks already delivered
s	The size of a single content chunk
$t_{\mathrm{dwell}}$	RSU dwell time of the requester
$D_{\mathrm{remain}}$	Remaining distance within RSU coverage for requester
v	Traveling speed of the requester
$C_{\mathrm{avail}}$	The deliverable size within RSU coverage
$r_1$	V2I transmission rate
$C_{\mathrm{def}}$	Content deficit to be compensated by relays in the outage zone
$t_{\mathrm{dwell},i}$	RSU dwell time of candidate i
$D_{\mathrm{remain},i}$	Remaining distance within RSU coverage and candidate i
$v_i$	Traveling speed of the requester and candidate i
$C_{\mathrm{pc},i}$	Maximum precachable size of $V_i$
$p_i,$	Relative position of candidate i to the requester
$p_{\mathrm{req}}\left(t_0\right),p_i\left(t_0\right)$	Initial position vectors of the requester and candidate i at time $t_0$
$v_i$	relative velocity of candidate i to the requester
$v_{\mathrm{req}}\left(t_0\right),v_i\left(t_0\right)$	Initial velocity vectors of the requester and candidate i at time $t_0$
$R_{V2V}$	Maximum V2V communication radius
$t_{\mathrm{in}},t_{\mathrm{out}}$	Expected entry and exit instants of the V2V communication range
$\Delta$	Discriminant of the quadratic intersection equation for V2V connection
$t_{\mathrm{conn},i}$	Expected V2V connection time of candidate vehicle i
$C_{\mathrm{conn},i}$	Connection-limited deliverable size of $V_i$
$C_{\mathrm{cap},i}$	Effective deliverable content capacity of candidate $V_i$
$i^{★}$	Index of the initially selected precaching vehicle
$C_{\mathrm{deficit}}$	Content deficits of the original requester
$C_{\mathrm{pre}}$	Amount of content already cached by a relay vehicle
$V_{\mathrm{req}}$	Original requester vehicle
$V_i$	Candidate precaching vehicle i
${\xi }_t(V_{\mathrm{req}},V_i)$	V2V connectivity indicator between the requester and $V_i$ at time t
$V_{\mathrm{pc}}$	and precaching vehicle
${\delta }_t(V_{\mathrm{req}},V_{\mathrm{pc}})$	Transmission overlap (half-duplex constraint) indicator caused by $V_{\mathrm{pc}}$
$r_{\mathrm{V}2\mathrm{V}}$	V2V transmission rate
$t_{o1},t_{o2}$	Start and end time of the outage-zone interval
$V_{\mathrm{DA}}$	Dynamic requester vehicle (precaching relay switching to requester)
$C_{\mathrm{def}}^{\mathrm{DA}}$	Content deficits of the dynamic requester
${\mathcal{V}}_{\mathrm{cand}}$	The set of candidate vehicles

4.1.1. Precaching Necessity Determination

This subsection delineates the process by which the incumbent RSU ascertains its capacity to deliver content to the requesting vehicle within the RSU coverage. Initially, the RSU gets the total size, $C_{total}$, and the total number of chunks, $N_{total}$, of the requested content from the REQ message received from the vehicle. It also determines the number of chunks that have already been delivered, $N_{delivered}$. The quantity of chunks that have been delivered is dependent on the requested chunk number contained within the REQ packet. On the basis of this information, the residual content size, $C_{rest}$, that has not yet been delivered is calculated as follows:

$$C_{rest}=(N_{total}-N_{delivered})\times s.$$

(1)

It is assumed that the size of the chunk, designated by s, remains constant to simplify the model. $C_{rest}$ denotes the minimum amount of data to be provided by the RSU in the future and serves as the basis for determining the necessity for precaching. The next step in the process is the RSU’s retrieval of the real-time location, speed, and route information of the vehicle that has made a request. This information is obtained from the mobility table of the vehicle. When the remaining travel distance from the current location to leave the RSU coverage is $D_{remain}$, the vehicle’s dwell time, $t_{dwell}$, is calculated as follows:

$$t_{\mathrm{dwell}}={\displaystyle \frac{D_{\mathrm{remain}}}{v}}.$$

(2)

where v is a velocity of the requester vehicle, which is known by periodic beacon message as explained in Section 3.

When content is being stored in the local cache, the physical layer transfer rate $r1$ of the WAVE interface is utilized without modification. The total amount of content that can be served, $C_{avail}$, is calculated as the product of the dwell time and the effective transfer rate, as follows:

$$C_{\mathrm{avail}}=r1\times t_{\mathrm{dwell}}.$$

(3)

The system determines the need for precaching by comparing $C_{rest}$ and $C_{avail}$, specifically triggering the precaching process if $C_{rest}$ is greater than $C_{avail}$ and otherwise considering it unnecessary. That is, the precaching procedure is activated whenever the RSU alone cannot transmit the remaining data within its coverage ($C_{\mathrm{rest}}>C_{\mathrm{avail}}$). In this case, the deficit the minimum amount that relays must compensate is defined as

$$C_{\mathrm{def}}\triangleq {\left(C_{\mathrm{rest}}-C_{\mathrm{avail}}\right)}^{+}=\max \left\{C_{\mathrm{rest}}-C_{\mathrm{avail}},0\right\}.$$

(4)

Equations (1)–(4) specify (i) the activation condition for precaching, (ii) the target quantity to be satisfied by relay selection and chunk scheduling, and (iii) the deficit-compensation constraint used later in the dual re-selection process when a relay transitions to a requester.

4.1.2. Initial Relaying Vehicle Selection

Following the identification of a requirement for precaching by the RSU, a precaching vehicle is selected, other than the vehicle that made the request, to deliver content to the Outage Zone. It is imperative that this step is performed to ensure the efficient utilization of network resources and to maximize the success rate of content delivery. The following steps must be taken to ensure the efficacy of the process. First, to narrow down the candidate search, the RSU considers only vehicles with the same or similar travel path as the requesting vehicle as potential relay candidates. By implementing this approach, the risk of connection failure, which may be caused by the exclusion of vehicles with different paths, is preemptively eliminated, thereby reducing computational complexity. The set of candidate vehicles is denoted by V, where V consists of vehicles that satisfy the path matching condition. Secondly, for each candidate vehicle in V, the RSU evaluates its delivery capability by calculating its precaching capacity based on its dwell time and its delivery capacity based on its connection time with the requesting vehicle.

The residence time $t_{\mathrm{dwell},\mathrm{i}}$ of a vehicle i within the RSU coverage is calculated as:

$$t_{\mathrm{dwell},\mathrm{i}}={\displaystyle \frac{D_{\mathrm{remain},\mathrm{i}}}{v_i}},$$

(5)

where candidate vehicle velocities $v_i$ are reported to the RSU through periodic beacon messages, $D_{\mathrm{remain},\mathrm{i}}$ is the calculation of the remaining travel distance of the vehicle i within the RSU coverage and $v_i$ is the velocity of the candidate vehicle i from its current location to its departure from the RSU coverage area. This value represents the maximum time that the RSU can perform precaching to that vehicle. Thus, by multiplying the previously defined effective transmission rate $r1$ and the dwell time, the total amount of data that can be delivered to a candidate vehicle i for precaching within the RSU $C_{\mathrm{pc},\mathrm{i}}$ is calculated as follows:

$$C_{\mathrm{pc},\mathrm{i}}=r1\times t_{\mathrm{dwell},\mathrm{i}}.$$

(6)

This value denotes the maximum content size that the RSU is capable of precaching for candidate vehicle i.

Next, we calculate the connection time between the requesting vehicle and the candidate vehicle (i). The connection time $t_{conn,i}$ means the time that the two vehicle remain in each other’s communication range based on the relative movement between the candidate vehicle (i) and the requesting vehicle after they enter the outage zone. We use a geometric closed-form model based on a unit disk to calculate the connection time $t_{\mathrm{conn},i}$. Let the requester vehicle be the reference at time $t_0$. Define the relative position and relative velocity of the candidate vehicle i as

$$p_i\triangleq p_i\left(t_0\right)-p_{\mathrm{req}}\left(t_0\right),v_i\triangleq v_i\left(t_0\right)-v_{\mathrm{req}}\left(t_0\right).$$

(7)

Similar to the velocity information, the position vectors $p_i\left(t_0\right)$ and $p_{\mathrm{req}}\left(t_0\right)$ are continuously updated to the RSU.

Assuming linear relative motion $p_i\left(t\right)=p_i+v_{i}t$ and a V2V communication radius $R_{V2V}$, the connection interval corresponds to the time during which the relative trajectory stays within the disk $\{x\in {\mathbb{R}}^2:\parallel x\parallel \le R_{V2V}\}$. Equivalently, the quadratic can be solved as follows:

$$\parallel p_i+v_i{t\parallel }^2=R_{V2V}^2⟺{\parallel v_i\parallel }^2{t}^2+2\left(p_i·v_i\right)t+\left(\parallel p_i{\parallel }^2-R_{V2V}^2\right)=0.$$

(8)

Let $\Delta$ denote the discriminant:

$$\Delta \triangleq {\left(p_i·v_i\right)}^2-{\parallel v_i\parallel }^2\left(\parallel p_i{\parallel }^2-R_{V2V}^2\right).$$

(9)

If $\Delta <0$, the trajectory does not intersect the disk; hence $t_{\mathrm{conn},i}=0$. Otherwise, the entry/exit instants are given by

$$t_{\mathrm{in}}={\displaystyle \frac{-p_i·v_i-\sqrt{\Delta }}{\parallel v_i{\parallel }^2}},t_{\mathrm{out}}={\displaystyle \frac{-p_i·v_i+\sqrt{\Delta }}{\parallel v_i{\parallel }^2}},$$

(10)

and the connection window length is

$$t_{\mathrm{conn},i}=\max \left\{0,t_{\mathrm{out}}-t_{\mathrm{in}}\right\}=\max \left\{0,{\displaystyle \frac{2\sqrt{\Delta }}{\parallel v_i{\parallel }^2}}\right\}.$$

(11)

For the degenerate case $\parallel v_i\parallel =0$, set $t_{\mathrm{conn},i}=+\infty$ if $\parallel p_i\parallel \le R_{V2V}$ and $t_{\mathrm{conn},i}=0$ otherwise.

Finally, with $t_{\mathrm{conn},i}$, the candidate vehicle’s connection-limited deliverable amount follows as by applying the transmission rate $r1$ of the WAVE interface

$$C_{\mathrm{conn},i}=r_1\times t_{\mathrm{conn},i},$$

(12)

which can be directly used in the min–max relay selection criterion together with the precached volume constraint.

For each candidate precaching vehicle $V_i$, denote the connection-limited deliverable amount by $C_{\mathrm{conn},i}$ and the available precached amount by $C_{\mathrm{pc},i}$. Given the residual content and the RSU-limited capacity $(C_{\mathrm{rest}},C_{\mathrm{avail}})$, the effective capability of $V_i$ is upper-bounded by

$$C_{\mathrm{cap},i}=\min \left\{C_{\mathrm{pc},i},C_{\mathrm{conn},i},C_{\mathrm{rest}},C_{\mathrm{avail}}\right\}.$$

(13)

Since $C_{\mathrm{rest}}$ and $C_{\mathrm{avail}}$ are independent of the candidate index i, maximizing (13) over i is equivalent to maximizing the two-way bottleneck between precached and connection limits:

$$i^{★}\in \arg \underset{i}{\max }\min \left\{C_{\mathrm{pc},i},C_{\mathrm{conn},i}\right\}.$$

(14)

Based on (14), the RSU identifies the optimal precaching vehicle $V_{i^{★}}$. Upon selection, the RSU transmits a SELECT message to $V_{i^{★}}$ containing the content information, the original requester ID, and the assigned precaching volume $\min \{C_{\mathrm{pc},i},C_{\mathrm{conn},i}\}$.

The RSU transmits a Select message to the designated precaching vehicle, containing the following three essential elements: Content ID, start index, and the total number of chunks. Following the receipt of the Select message, the precaching vehicle is required to transmit a Precache message that contains equivalent information to the RSU, thereby signifying its readiness for precaching. The RSU transmits data that falls within the range of chunks specified in the Precache message, thus, avoiding unnecessary network load. Once the process of precaching has been completed, the precaching vehicle initiates the continuous transmission and reception of beacon messages within the designated Outage Zone. These messages are utilized for the purpose of tracking the location of the requesting vehicle. Upon entering communication range, the precaching vehicle delivers the precached content, thereby ensuring a latency-free service. It shows that the initial precaching vehicle selection procedure proposed in this section is conducive to the reliability and efficiency of content delivery.

4.2. Handling Content Request from a Relaying Vehicle

This section is concerned with issues that arise when the initial precaching vehicle transitions to a different role upon fulfilling a content request. Firstly, Section 4.2.1 delineates the information flows that should be exchanged between the RSU and the vehicle when the precaching vehicle transitions to the requesting vehicle. Such information includes location, speed, and the amount of precaching completed. The text also provides a detailed description of the process for accurately estimating the amount of existing precached content, the remaining dwell time, and the connectivity time, based on the information provided. In the following section, we propose an algorithm for the selection of additional precaching vehicles, with the aim of addressing the content shortage experienced by the original requesting vehicle. In addition, the calculation formula for the shortage and the evaluation criteria for the candidate vehicle are described, along with the formula itself. Section 4.2.3 then introduces the procedure for selecting the vehicles to be immediately precached for the existing precaching vehicles that are now the new requesting vehicles. It also specifies the message exchange and timing management scheme that the RSU should perform in this process. This configuration ensures efficient content delivery and guarantees service continuity in any scenario where a precaching vehicle transitions to a requester.

4.2.1. Communication and Information Exchange

If an existing precaching vehicle requests new content for itself within the RSU’s coverage, the role of the vehicle is subject to transition from precaching vehicle to request vehicle. In that case, the existing precaching vehicle is required to provide the RSU with its mobility information. Furthermore, the precaching vehicle transmits to the RSU the quantity of content chunks that have previously been downloaded and precached, in addition to the percentage of the aggregate content that has been downloaded to date. This detailed communication enables the RSU to ascertain the vehicle’s current state and its precaching status, thus, facilitating the maintenance of service.

The RSU employs the information received from the precaching vehicle to swiftly evaluate the aggregate amount of previously precached content and its status. The RSU’s function is to estimate the maximum amount of time that the vehicle can receive additional content while within the RSU’s coverage area. This process is based on the vehicle’s movement information. To accomplish this objective, the RSU calculates the remaining dwell time by dividing the vehicle’s remaining distance traveled $D_{remain}$ by the vehicle’s current speed v. This calculated residual dwell time delineates the limit of time that the RSU is able to utilize to deliver new content requested by the precaching vehicle. Consequently, the RSU is able to plan efficient content delivery and precaching based on this information.

Furthermore, upon a vehicle transitioning to a new requesting vehicle role, the RSU performs a re-evaluation of the anticipated connectivity time $t_{conn}$ within the Outage Zone in conjunction with the existing requesting vehicle. To accomplish this objective, the RSU undertakes a thorough examination of the present location, the trajectory of travel, and the respective velocities of the two vehicles. This analysis enables the RSU to formulate a precise estimation of the duration for which the two vehicles can remain within each other’s communication range within the designated Outage Zone. Through this prediction, the RSU maintains the reliable and uninterrupted delivery of content to the requesting vehicle. Furthermore, the RSU proactively identifies and minimizes potential issues such as content loss or service interruptions that may occur during the role switching process. This step-by-step and detailed information exchange and calculation process is essential to minimize the impact of vehicle role switching on service quality.

4.2.2. Selection of Additional Relaying Vehicle for the Original Requester Vehicle

When an existing precaching vehicle requests new content and is converted to a requesting vehicle, the content delivery plan for the original requesting vehicle is consequently challenged. The existing precaching vehicle may discard some or all of the content it has already precached, resulting in traffic wastage and difficulties in serving the existing request vehicle. To address this issue, the RSU calculates the content deficit $C_{deficit}$ that must be delivered to the prevailing request vehicle and expeditiously selects a new precaching vehicle to compensate for it. The deficit is expressed by the following formula:

$$C_{\mathrm{deficit}}=C_{\mathrm{rest}}-C_{\mathrm{pre}},$$

(15)

where $C_{rest}$ denotes the total content that the original requesting vehicle has not yet received from the RSU, while $C_{pre}$ signifies the content that has already been precached by the existing precaching vehicle. During the role transition, the precaching vehicle transmits a REQ message to the RSU, indicating the already precached chunks.

In light of the data mentioned above, the RSU will select the most appropriate vehicle from the set of candidate vehicles. The following formula is used to select the optimal vehicle:

$$\begin{array}{cc}\hfill \underset{{\xi }_t(V_{req},V_i)}{\max }\sum _{t=t_{o1}}^{t_{o2}}& \left[({\xi }_t(V_{req},V_i)\times \left(1-{\delta }_t(V_{req},V_{pc})\right)\times r_{V2V}\right]\hfill \end{array}$$

(16)

$$s.t.\sum _{t=t_{o1}}^{t_{o2}}{\xi }_t(V_{req},V_i)\le min(t_{dwell},t_{dwell,i})$$

(17)

$${\xi }_t(V_{req},V_i)\in \{0,1\}$$

(18)

$${\delta }_t(V_{req},V_{pc})\in \{0,1\}$$

(19)

where $V_{req}$ is the vehicle requested previously, $V_{pc}$ is a vehicle that changes from a precaching vehicle to a request vehicle, $V_i$ is the candidate newly selected vehicle for maintaining service of $V_{req}$, ${\xi }_t(V_{req},V_i)$ denotes the delivery of precaching chunks from $V_i$ to $V_{req}$ at time t, ${\delta }_t(V_{req},V_{pc})$ denotes the delivery of precached chunks from $V_{pc}$ to $V_{req}$ at time t, and $r_{V2V}$ denotes the data rate of V2V communication. The RSU obtains the positions and velocities of vehicles via their periodic beacon messages. Using these data, it calculates $t_{dwell}$ and $t_{dwell,i}$ according to (2) and (5), respectively.

The optimization formulated in (16) seeks to select a new precaching vehicle from a candidate set to maintain continuous service for the original requester. When the existing precaching vehicle $V_{pc}$ transitions to a requester role, it becomes unable to provide the required transmission capacity within the outage zone. Nevertheless, DRAS obligates $V_{pc}$ to deliver its cached chunks. The binary indicator ${\delta }_t(V_{req},V_{pc})$ characterizes the time intervals during which $V_{pc}$ transmits these chunks to $V_{req}$. Since $V_{req}$ does not support concurrent receptions from multiple transmitters, any overlapping intervals must be excluded from the candidate’s transmission window. This constraint is captured by the term $(1-{\delta }_t(V_{req},V_{pc}))$, which restricts a candidate $V_i$ to transmit only when $V_{pc}$ is not transmitting to $V_{req}$. Accordingly, the formulation selects the optimal candidate $V_i$ that maximizes the deliverable content within the remaining non-overlapping communication interval.

4.2.3. Selection of Precaching Vehicle for the Dynamic Requester Vehicle

When an existing precaching vehicle switches its role to a requester vehicle, the RSU first determines whether additional relaying is required following the procedure described in Section 4.1. Using the most recent information on vehicle location, travel speed, and remaining dwell time within the RSU coverage, the RSU evaluates whether requested content can be fully delivered through V2I communication alone. If this condition is not satisfied, additional precaching vehicles are selected to support content delivery in the outage zone.

The RSU selects a precaching vehicle for the newly transitioned requester ($V_{\mathrm{DA}}$) while maintaining priority for continuous service to the original requester. Specifically, the amount of content that cannot be delivered via V2I communication is defined as the data deficit $C_{\mathrm{def}}^{\mathrm{DA}}$, which must be compensated by a designated precaching vehicle within the outage zone. To prevent resource conflicts and ensure independent delivery, the vehicle already assigned as the new precaching vehicle for the original requester is explicitly excluded from the candidate set $V_{\mathrm{cand}}$.

To identify the optimal precaching vehicle for $V_{\mathrm{DA}}$, the RSU employs an evaluation logic analogous to (16)–(19). The objective is reformulated to maximize the cumulative amount of content delivered to $V_{\mathrm{DA}}$, given by

$$\underset{V_i\in {\mathcal{V}}_{\mathrm{cand}}}{\max }\sum _{t=t_{DA1}}^{t_{DA2}}\left[{\xi }_t(V_{\mathrm{DA}},V_i)·\left(1-{\delta }_t(V_{\mathrm{req}},V_{\mathrm{DA}})\right)·r_{\mathrm{V}2\mathrm{V}}\right].$$

(20)

The associated constraints are adapted to account for $C_{\mathrm{def}}^{\mathrm{DA}}$.

Since $V_{\mathrm{DA}}$ must forward its cached chunks to the original requester ($V_{\mathrm{req}}$), it cannot receive data concurrently from any candidate precaching vehicle. This constraint is governed by the transmission indicator ${\delta }_t(V_{\mathrm{req}},V_{\mathrm{DA}})$, which specifies the time intervals during which $V_{\mathrm{DA}}$ is transmitting to $V_{\mathrm{req}}$. Accordingly, the term $(1-{\delta }_t(V_{\mathrm{req}},V_{\mathrm{DA}}))$ restricts candidate precaching vehicles from transmitting to $V_{\mathrm{DA}}$ during these intervals.

By solving this optimization, the RSU identifies a precaching vehicle that compensates for the content deficit of $V_{\mathrm{DA}}$ within the available non-overlapping communication interval. This formulation ensures that the role transition of a precaching vehicle does not compromise service continuity, thereby preserving reliable content delivery under dynamic role changes.

5. Energy-Efficient Dynamic Relay Assignment Scheme

This section presents EE-DRAS, an enhanced relay selection framework that integrates energy-awareness into RSU-driven precaching. Unlike conventional DRAS, which prioritizes transmission performance based on metrics such as distance stability, RSU dwelling duration, or link reliability, EE-DRAS explicitly models the power consumption incurred during both V2I precaching and V2V relaying. Since autonomous vehicles operate entirely on battery power, excessive transmission energy directly reduces driving range, battery lifetime, and communication availability. Therefore, an energy-centric relay selection method is essential to ensure sustainable and efficient operation in future vehicular networks.

This section consists of three subsections. Section 5.1 develops a detailed relay candidate profiling mechanism that incorporates mobility, channel stability, and energy-related contextual information. Section 5.2 builds an energy model for V2I and V2V communication, computes total per-vehicle energy consumption, and derives an energy-efficiency score. Section 5.3 fuses this energy-efficiency metric with conventional DRAS metrics to construct a hybrid relay selection score. The Table 3 is the summary of all symbols in Section 5.

Table 3. Notation Summary for Section 5.

Symbol	Description
$P_{r,\mathrm{tar}}\left(m\right)$	Target received power necessary to sustain MCS m
$P_{\mathrm{sens}}\left(m\right)$	Receiver sensitivity constraint for MCS m
$M_{\mathrm{dB}}$	Link margin accounting for channel uncertainty (dB)
$P_{tx,\mathrm{req}}\left(d\right)$	Required transmit power at distance d
$G_t, G_r$	Transmitter and receiver antenna gains
$PL\left(d\right), \gamma , X_{\sigma }$	Path-loss (dB), path-loss exponent, and log-normal shadowing variable
$G_{\mathrm{path}}\left(d\right)$	Linear-scale path gain derived from path-loss
$P_r\left(d\right)$	Actual received power at distance d
$P_r^{V2I}\left(d\right), P_r^{V2V}\left(d\right)$	Empirical required power models for V2I and V2V links
$d\left(t\right)$	Time-varying distance between communicating nodes
$\Delta t$	Time slot duration for power accumulation
${\mu }_t, {\xi }_t$	RSU dwell indicator and V2V connectivity indicator at time t
$E_{V2I}, E_{V2V}$	Transmission energy consumed during V2I precaching and V2V forwarding
$E_{\mathrm{total},i}$	Total transmission energy of candidate vehicle i
$D_i$	Total transmitted data volume of candidate vehicle i
$E_{b,i}$	Bit-level energy consumption of candidate vehicle i
${\eta }_i$	Energy efficiency of candidate vehicle i
$S_{\min }, S_{\max }$	Minimum and maximum raw DRAS scores across all candidates
${\tilde{\eta }}_i, {\tilde{D}}_i$	Min-max normalized energy efficiency and data delivery volume of $V_i$
${\tilde{S}}_i^{DRAS}$	Min-max normalized DRAS score of candidate vehicle i
$S_i^{EE}, S_i^{DRAS}$	Energy-efficiency score and raw DRAS score of candidate vehicle i
$S_i^{Hybrid}$	Hybrid relay selection score of candidate vehicle i
$V^{*}, C$	Candidate vehicle set and the selected optimal precaching vehicle

5.1. Candidate Relay Vehicle Profiling

The relay selection process begins with the RSU periodically scanning the vehicles within its coverage and constructing a comprehensive profile for each potential relay. Unlike traditional DRAS, which primarily depends on instantaneous mobility parameters, EE-DRAS incorporates a richer and more diverse set of indicators that collectively determine a vehicle’s suitability as an energy-efficient relay.

To begin with, the RSU collects fundamental mobility information such as each vehicle’s position, velocity, acceleration, heading, and predicted trajectory. A trajectory-based estimation model is then applied to predict the vehicle’s future movement within the RSU coverage, enabling accurate estimation of its expected dwelling time. This dwelling time directly influences how much V2I precaching the vehicle can receive before leaving the coverage area.

In addition to mobility indicators, the RSU evaluates several communication-related parameters that affect link reliability and coverage stability. These include estimated path-loss, supported MCS levels, transmit power capability, antenna gains, and other physical-layer characteristics. Such parameters reflect the feasibility of maintaining reliable V2I and V2V communication during both the precaching and relaying phases.

From an energy-efficiency perspective, EE-DRAS further records key metrics required for calculating transmission energy. These include the time-varying distance between communicating nodes $d\left(t\right)$, the RSU coverage indicator ${\mu }_t\in \{0,1\}$, and the V2V link connectivity indicator ${\xi }_t\in \{0,1\}$, each representing whether the corresponding V2I or V2V communication link is available at time t.

Through this extended profiling procedure, EE-DRAS builds a multidimensional candidate model that integrates mobility patterns, channel stability, and anticipated energy consumption. This enriched profile serves as the foundation for the energy-efficiency evaluation presented in Section 5.2 and the hybrid relay selection mechanism described in Section 5.3.

5.2. Energy-Efficiency–Based Relay Evaluation

EE-DRAS quantifies the energy cost of precaching by modeling the transmission power required during both the V2I precaching phase and the V2V forwarding phase, thereby evaluating the total energy consumed by each candidate vehicle throughout the entire process. The procedure begins by defining the target received power necessary to sustain the selected MCS level, expressed as

$$P_{r,\mathrm{tar}}\left(m\right)=P_{\mathrm{sens}}\left(m\right)+M_{\mathrm{dB}},$$

(21)

where $P_{\mathrm{sens}}\left(m\right)$ represents the minimum sensitivity required for MCS m, and $M_{\mathrm{dB}}$ accounts for channel uncertainty such as fading, mobility-induced fluctuations, and environmental variations to ensure a reliable communication margin. To satisfy this target at a distance d, the required transmit power is calculated using the link budget equation

$$P_{tx,\mathrm{req}}\left(d\right)=P_{r,\mathrm{tar}}-G_t-G_r+PL\left(d\right),$$

(22)

in which the antenna gains $G_t$ and $G_r$ reduce the necessary transmit power, and the path-loss $PL\left(d\right)$ is modeled by the IEEE 802.11p log-distance formulation

$$PL\left(d\right)=PL\left(d_0\right)+10\gamma {\log }_{10}\left({\displaystyle \frac{d}{d_0}}\right)+X_{\sigma },$$

(23)

incorporating the reference loss $PL\left(d_0\right)$, the path-loss exponent $\gamma$, and the shadowing term $X_{\sigma }$ to capture real-world attenuation characteristics. From this path-loss, the linear-scale path gain is obtained as

$$G_{\mathrm{path}}\left(d\right)={10}^{-PL\left(d\right)/10},$$

(24)

and the resulting received power at a distance d becomes

$$P_r\left(d\right)=P_t·G_t·G_r·G_{\mathrm{path}}\left(d\right),$$

(25)

which represents the actual signal strength delivered to the receiver after propagation loss.

To reflect realistic vehicular communication environments, EE-DRAS further adopts measurement-based empirical models for V2I and V2V links:

$$P_r^{V2V}\left(d\right)={10}^{-4.89}{d}^{-\gamma },P_r^{V2I}\left(d\right)={10}^{-4.09}{d}^{-\gamma }.$$

(26)

By accumulating these power values over the time slot interval $\Delta t$, the V2I energy consumption during periods when the vehicle remains within the RSU coverage (${\mu }_t=1$) is computed as

$$E_{V2I}=\sum _{t=0}^{t_0}\left[P_r^{V2I}\left(d\left(t\right)\right)·{\mu }_t\Delta t\right],$$

(27)

representing the energy expenditure for receiving precached data. Similarly, the V2V forwarding energy during intervals in which a feasible link to the requesting vehicle exists (${\xi }_t=1$) is given by

$$E_{V2V}=\sum _{t=1}^{{\omega }_2}\left[P_r^{V2V}\left(d\left(t\right)\right)·{\xi }_t\Delta t\right].$$

(28)

The total energy consumed throughout the complete precaching and relaying cycle is, therefore,

$$E_{\mathrm{total}}=E_{V2I}+E_{V2V}.$$

(29)

Based on the total amount of delivered data, the per-bit energy consumption and energy efficiency for each candidate $V_i$ are defined as

$$E_{b,i}={\displaystyle \frac{E_{\mathrm{total},i}}{D_i}},{\eta }_i={\displaystyle \frac{1}{E_{b,i}}},$$

(30)

implying that efficiency increases with higher data delivery and lower energy consumption. Since ${\eta }_i$ and $D_i$ have different physical units and numerical scales, directly combining them may introduce numerical bias. To address this, EE-DRAS independently applies standard min–max normalization to each metric across all candidates $V_i\in \mathcal{C}$, mapping them to the dimensionless range $[0,1]$, denoted as ${\tilde{\eta }}_i$ and ${\tilde{D}}_i$, respectively.

Accordingly, a composite selection score is assigned to each candidate $V_i$ by integrating both objectives:

$$S_i^{EE}={\displaystyle \frac{{\tilde{\eta }}_i+{\tilde{D}}_i}{2}}.$$

(31)

Since the energy efficiency and data delivery metrics are normalized as [0, 1] scale, EE-DRAS integrates these two values to evaluate the candidate’s capabilities simultaneously.

5.3. Hybrid Relay Selection for EE-DRAS

While the energy-efficiency score quantifies the transmission energy required for a candidate vehicle to complete V2I precaching and V2V forwarding, relying solely on power-related metrics may overlook critical aspects of network reliability, such as mobility stability and sustained V2V connectivity. In dynamic vehicular environments, a candidate with high energy efficiency may still be unsuitable if its relative motion leads to short contact durations or frequent link disruptions. Therefore, EE-DRAS integrates energy-oriented and connectivity-oriented criteria by combining the conventional DRAS metric with the energy-efficiency score introduced in Section 5.2. The traditional DRAS mechanism evaluates the reliability of a candidate relay $V_i$ in maintaining a V2V connection with the requesting vehicle $V_{\mathrm{req}}$. During the outage zone interval $[t_{o1},t_{o2}]$, DRAS evaluates the effective V2V transmission opportunity while accounting for time intervals occupied by transmissions from the existing precaching vehicle $V_{\mathrm{pc}}$. This is mathematically formulated by the DRAS score:

$$S_i^{DRAS}=\sum _{t=t_{o1}}^{t_{o2}}\left[{\xi }_t(V_{req},V_i)·\left(1-{\delta }_t(V_{req},V_{pc})\right)·r_{V2V}\left(t\right)\right],$$

(32)

where ${\xi }_t(V_{\mathrm{req}},V_i)\in \{0,1\}$ denotes the V2V link availability, ${\delta }_t(V_{\mathrm{req}},V_{\mathrm{pc}})\in \{0,1\}$ indicates the half-duplex constraint intervals during which $V_{\mathrm{pc}}$ is transmitting, and $r_{V2V}\left(t\right)$ represents the achievable V2V transmission rate at time t. This formulation reflects the DRAS objective of maximizing V2V throughput while avoiding concurrent transmissions. Although DRAS effectively identifies candidates with stable connectivity, its raw score $S_i^{DRAS}$ cannot be directly aggregated with the bounded energy-efficiency score $S_i^{EE}$ due to differences in units and numerical scales. To integrate these heterogeneous metrics within a unified decision framework, EE-DRAS applies min–max normalization to the raw DRAS score, mapping it into a dimensionless indicator ${\tilde{S}}_i^{DRAS}\in [0,1]$, where

$${\tilde{S}}_i^{DRAS}={\displaystyle \frac{S_i^{DRAS}-S_{\min }}{S_{\max }-S_{\min }}},$$

(33)

where $S_{\min }$ and $S_{\max }$ denote the minimum and maximum raw DRAS scores across all candidates in $\mathcal{C}$, respectively. Subsequently, EE-DRAS constructs the hybrid metric by integrating the normalized DRAS score and the composite energy score:

$$S_i^{Hybrid}={\displaystyle \frac{{\tilde{S}}_i^{DRAS}+S_i^{EE}}{2}}.$$

(34)

This integrated metric allows the RSU to evaluate the connectivity and the energy efficiency of each candidate vehicle. Ultimately, the RSU selects the optimal metric $V^{*}$ as follows:

$$V^{*}=\arg \underset{V_i\in \mathcal{C}}{\max }{S}_i^{Hybrid},$$

(35)

By assigning the relay that maximizes this integrated metric, EE-DRAS guarantees a content delivery that balances throughput stability with energy preservation. Furthermore, the protocol’s continuous monitoring ensures that any role transitions among precaching vehicles are managed through automated dual re-selection without disrupting the original requester’s service. Consequently, the proposed scheme mitigates the fundamental challenges of intermittent outage-zone disconnections and localized energy constraints.

6. Performance Evaluation

In this section, we evaluate the performance of the proposed scheme. For performance evaluation, we compare the proposed scheme with the latest precaching scheme named MPVS [13] by simulations. To simulate this scheme, we use NS3 [33] as a simulation tool. As the network model of a vehicular environment for our simulations, a 5 km × 5 km urban area is configured in a grid-shaped Manhattan mobility model [34]. Each intersection on the roads in the simulated network has a single RSU, resulting in a uniform place of RSUs. The RSUs are connected by high-speed backhaul links, which feature a transmission rate of 10 Gbps and a latency of 10ms. This enables them to exchange content with the content server and among themselves. Each RSU has a capacity of 1 TB to cache content, and provides content for vehicles via WAVE communication. Vehicles are programmed to navigate the grid-shaped streets of Manhattan according to a predetermined route that is shortest path to random destinations. The speed of each vehicle is sampled based on a Gaussian distribution at the beginning. Vehicles download content from RSUs through WAVE when they request it or have to precache it. The vehicle periodically requests content from RSUs according to a probability that follows the Poisson distribution, with an average interval based on vehicle density. The popularity of content follows a Zipf distribution with an exponent of 0.75, derived from a pool of 1,000,000 items. Each content is subdivided into chunks of 2 MB [35]. Vehicles have 256 GB storage for cache, and they can relay precached content in outage zone. The parameters of our simulations are detailed in Table 4.

Table 4. Simulation Parameters.

Parameters	Value
Simulation time	3600 s
Network size	5 km × 5 km
Distance between RSUs	3 km
Vehicle mobility model	Manhattan case
Backhaul link latency	10 ms
Backhaul link rate	10 Gbps
Maximum $r_j\left(t\right)$	54 Mbps
An exponent of content popularity	0.75
Chunk size	25 kbytes
RSU transmission range	800 m
Vehicle’s CS	256 GB
RSU’s CS	1 TB
Vehicle density	[5, 40] per km2
Vehicle’s average speed	[10, 100] km/h
Content request period mean $\lambda$	15 s
Size of requested content	[300, 1500] MB

We consider the following parameters to evaluate the four performances in variable environments.

• Vehicle density: It is a metric that quantifies the number of vehicles per unit area.
• Probability of being a requester vehicle: It is a numerical value that quantifies the probability of a vehicle requesting within a specified period of time.
• Vehicle velocity: It denotes the average speed at which vehicles travel within the network.
• Requested content size: It refers to the amount of content requested by the vehicle.

We measure the following metrics to compare the three performances of the schemes.

• The total content download size: The total volume of content successfully delivered to requesting vehicles across the network.
• The average delay to be a requester: The average waiting time a precaching vehicle experiences before it is permitted to initiate its own content request. This metric evaluates service fairness among vehicles.
• The total energy usage: The total energy consumption denotes the total energy expended by the RSU and vehicles during content precaching and delivery. Since identical data volumes may require different transmission and reception power depending on relay selection and channel conditions, this metric effectively reflects the energy efficiency of the scheme.

For the first metric, a higher value indicates better throughput and efficiency. For the second metric, a lower value reflects fairer waiting times for a relay to become a requester. Finally, a lower value in the third metric demonstrates superior energy efficiency without performance loss.

Figure 3a illustrates that, as vehicle density increases, all schemes exhibit a steady growth in the total amount of downloaded content. This trend appears because a denser environment increases V2V encounter opportunities, enabling cached data to be delivered more frequently to requesting vehicles. EE-DRAS consistently achieves a larger downloaded volume than DRAS and SRP, due to its energy-aware relay selection that preserves more reliable transmission paths. These observations confirm that EE-DRAS maintains the most favorable content-delivery capability in highly populated road scenarios.

Figure 3. Performance according to vehicle density: (a) the total content download size, (b) the average delay to be a requester vehicle, and (c) the total energy usage.

As shown in Figure 3b, as density becomes higher, DRAS and SRP experience increased delay, while EE-DRAS maintains a relatively stable latency profile. With more vehicles, interference and contention intensify, reducing link quality and leading to additional retransmissions in DRAS and SRP. EE-DRAS mitigates this delay escalation by prioritizing relays with stronger link characteristics, thereby avoiding inefficient transmissions. Consequently, EE-DRAS demonstrates better delay resilience in congested traffic conditions.

Figure 3c shows that, when the number of vehicles grows, DRAS and SRP show a sharp increase in energy usage, whereas EE-DRAS exhibits only a moderate increase. This occurs because dense networks tend to trigger more high-power transmissions and a greater likelihood of repeated attempts in DRAS and SRP. In contrast, EE-DRAS reduces energy expenditure by selecting relays that require lower transmission power due to favorable channel conditions. The results indicate that EE-DRAS is substantially more power-efficient in crowded vehicular environments.

Figure 4a illustrates that, as vehicle speed increases the total downloaded content diminishes for all three protocols. The shortening of contact durations at higher speeds restricts successful V2V data transfers, reducing the overall delivered volume. EE-DRAS retains a higher download amount than DRAS and SRP because its relay selection approach favors links with greater temporal stability. This implies that EE-DRAS is more robust to mobility-induced degradation in fast-moving traffic.

Figure 4. Performance according to the average of vehicle speed: (a) the total content download size, (b) the average delay to be a requester vehicle, and (c) the total energy usage.

As shown in Figure 4b, the increasing velocity leads to a significant delay escalation in DRAS and SRP, while EE-DRAS maintains much lower latency. Rapid movement causes frequent link breakages in DRAS and SRP, resulting in repeated transmission attempts and accumulated waiting time. EE-DRAS effectively avoids unstable relays, thereby limiting the occurrence of disconnections and reducing delay growth. Therefore, EE-DRAS provides stronger service continuity in high-mobility environments.

Figure 4c shows that, the energy consumption decreases for all schemes as vehicle speed increases. Higher mobility shortens contact intervals, which in turn limits the total number of transmissions and reduces active communication time. Even under identical speed levels, EE-DRAS consistently consumes less energy than DRAS and SRP due to its optimized relay selection strategy. These findings demonstrate that EE-DRAS is particularly energy-efficient when vehicles move at high velocities.

Figure 5a illustrates that, larger content sizes result in increased downloaded volume across all methods. As the requested data size grows, the total amount transferred through both RSU and V2V links inevitably rises. EE-DRAS continues to deliver a greater volume than the comparison schemes, benefiting from more effective relay selection especially when handling sizable data objects. This suggests that EE-DRAS is well-suited for distributing large multimedia or high-resolution content.

Figure 5. Performance according to the content size: (a) the total content download size, (b) the average delay to be a requester vehicle, and (c) the total energy usage.

As shown in Figure 5b, as content size expands, delay grows noticeably in DRAS and SRP, while EE-DRAS experiences a smaller and more controlled increase. Larger payloads extend transmission durations, which directly contributes to higher service latency. EE-DRAS alleviates this effect by choosing more efficient relays that reduce overall transmission time, keeping latency relatively constrained. This demonstrates EE-DRAS’s capability to maintain stable service levels even with large-scale content.

Figure 5c show that, the energy consumption rises as the content size becomes larger for all evaluated mechanisms. Since bigger files require more data transmissions, communication time and power usage naturally increase. EE-DRAS, however, shows a slower growth rate compared to DRAS and SRP because its relay selection minimizes unnecessary energy expenditure. These results highlight that EE-DRAS preserves stronger energy-efficiency advantages when handling large content volumes.

Figure 6a presents that, the total downloaded content versus the request probability, showing that all schemes benefit from higher request activity. As more vehicles initiate content requests, the overall volume of transferred data increases accordingly. EE-DRAS surpasses DRAS and SRP by handling frequent requests more effectively through improved relay selection. Thus, EE-DRAS offers the highest delivery capability in environments with heavy content-request demand.

Figure 6. Performance according to the probability to be a requester vehicle: (a) the total content download size, (b) the average delay to be a requester vehicle, and (c) the total energy usage.

Figure 6b shows that, as the request probability rises, DRAS and SRP experience increasing delay, while EE-DRAS shows a much more gradual latency rise. A higher number of requests intensifies channel contention and may trigger more retransmissions, contributing to longer waiting times. EE-DRAS counteracts this by selecting more reliable relays, thereby mitigating the delay impact of request congestion. This confirms that EE-DRAS upholds latency stability under heavy request loads.

Figure 6c illustrates that a higher probability of a request leads to higher energy usage in all approaches. As the number of transmissions grows with increasing demand, total power consumption naturally rises. EE-DRAS sustains significantly lower energy consumption by avoiding inefficient relay paths and ensuring reduced transmission power for each transfer. Therefore, EE-DRAS preserves superior energy-saving performance even when the request activity is high.

7. Conclusions

In this paper, we have introduced a dynamic relay assignment scheme that detects when a vehicle originally selected as a precaching vehicle issues its own content request and, without discarding any already-cached chunks, preserves and delivers those chunks to the original requester. This scheme ensures that precious network resources are not wasted and that there are no service interruptions when a relay vehicle becomes a requester vehicle. First, we developed a simultaneous reselection scheme that, upon detecting a precaching vehicle’s new request, immediately appoints one vehicle to serve the original requester’s deficit and a separate vehicle to serve the newly designated requester. By coordinating two precaching vehicles in parallel, our scheme maintains uninterrupted service continuity for both requesters. Then, we formalized the selection of the two precaching vehicles and the chunk allocation challenge as an integer linear programming problem that jointly accounts for each candidate vehicle’s dwell time in the RSU, the connectivity within the outage zone, and the maximum precaching capacity. We demonstrated that this ILP can be solved in real time within the NS-3 simulation environment, enabling the RSU to make optimal precaching decisions. Finally, our NS3-based simulations validated the efficacy of the proposed scheme, showing substantial improvements in the total content download size and a marked reduction in the delay to be a requester compared to the existing V2V precaching schemes. These empirical gains confirm that our dynamic relay assignment scheme delivers both efficiency and reliability within the outage zone in vehicular networks.

This paper demonstrates improvements in content delivery and energy efficiency. However, it remains subject to several practical limitations. First, the proposed scheme assumes deterministic vehicle trajectories. In real-world vehicular environments, vehicles exhibit unexpected mobility patterns, such as lane changes, temporary stops, and traffic congestion. These unprecedented movements can cause estimation errors in the calculation of dwell times and connectivity windows. To address these mobility uncertainties, our future work will explore a supervised learning techniques to proactively predict mobility deviations and a reinforcement learning algorithms to enable adaptive relay selection decisions in dynamically changing environments. Furthermore, the current model does not account for beacon packet losses during communications. Practical communication systems inevitably experience beacon losses due to signal attenuation and channel interference. Therefore, we plan to conduct further research to systematically enhance communication reliability and overall system performance by explicitly incorporating beacon loss models.