Supporting Immersive Video Streaming via V2X Communication

Abstract

With the rapid advancement of autonomous driving and network technologies, future vehicles will function as network nodes, facilitating information transmission. Concurrently, in-vehicle entertainment systems will undergo substantial enhancements. Beyond traditional broadcasting and video playback, future systems will integrate immersive applications featuring 360-degree views and six degrees of freedom (6DoF) capabilities. As autonomous driving technology matures, vehicle passengers will be able to engage in a broader range of entertainment activities while on the move. However, this evolution in video applications will significantly increase bandwidth demand for vehicular networks, potentially leading to bandwidth shortages in congested traffic areas. This paper presents a method for bandwidth allocation for vehicle video applications within the landscape of vehicle-to-everything (V2X) networks. By utilizing a millimeter-wave (mmWave), terahertz (THz) frequency band, and cell-free (CF) extremely large-scale multiple-input multiple-output (XL-MIMO) wireless communication technologies, we provide vehicle passengers with the necessary bandwidth resources. Additionally, we address bandwidth contention issues in congested road segments by incorporating communication methods tailored to the characteristics of vehicular environments. By classifying users and adjusting according to the unique requirements of various multimedia applications, we ensure that real-time applications receive adequate bandwidth. Simulation experiments validate the proposed method’s effectiveness in managing bandwidth allocation for in-vehicle video applications within V2X networks. It increases the available bandwidth during peak hours by 32%, demonstrating its ability to reduce network congestion and ensure smooth playback of various video application types.

1. Introduction

Recent literature indicates that numerous studies have proposed improvements in compression efficiency and bitrate reduction for multimedia applications and explored the potential of emerging network technologies for mobile networks. As autonomous driving technology matures, future vehicles will not only possess autonomous driving capabilities but also offer more diverse onboard entertainment systems. Passengers will be able to participate in immersive remote meetings and experiments, as well as enjoy immersive games and high-quality streaming media services. These emerging multimedia applications will demand substantial bandwidth and extremely high throughput within vehicular networks.

To address the streaming requirements in vehicular networks, Feng et al. [1] examined caching strategies for the dynamic characteristics of vehicular networks and proposed an adaptive dynamic resource management scheme for hierarchical cooperative caching networks. Shin et al. [2] utilized a 3D vector mobility prediction algorithm in their protocol to predict vehicle mobility, enabling flexible responses to dynamic topology changes and achieving high frame transmission rates. Alaya et al. [3] introduced an inter-layer approach for multimedia streaming in vehicular networks, dynamically adjusting transmission rates to enhance video playback stability and packet transmission rates in vehicles. However, these studies have not fully considered the advantages of future 6G network technologies in vehicle communications and the impact of bandwidth demand differences for various multimedia applications.

Recently, the popularity of smart devices and communication technologies has driven rapid growth in immersive games and high-quality streaming media services. These emerging multimedia applications demand substantial bandwidth and extremely high network throughput [4,5]. The quality of the video experience (QoE) has a significant impact on the likelihood of a user making a repeat purchase. Conversely, poor video QoE can result in a loss of users. Consequently, it is of paramount importance for wireless network operators to ensure that the user-perceived QoE is as high as possible.

To meet these future potential demands, the Moving Picture Experts Group (MPEG) has established various video coding standards. Among these, Advanced Video Coding (AVC) stands out for its low encoding complexity and broad compatibility, making it the most widely used video codec standard currently [6]. As the next-generation video coding standard, Versatile Video Coding (VVC) offers higher compression efficiency compared to AVC, reducing data size by 75% while maintaining the same level of visual quality [7]. MPEG has also introduced Low Complexity Enhancement Video Coding (LCEVC), which enhances basic codecs with an additional low bitrate layer to improve video compression and transmission efficiency. LCEVC reduces the resolution of the input original video by half to form a low-quality video base layer, then encodes the differences between the low-quality video and the original video to generate an enhancement layer. Upon decoding at the client end, the LCEVC decoder combines the base layer and enhancement layer to produce video with the same resolution as the original, achieving bitrate reduction [8].

A key component of immersive applications is 360-degree video, which demands higher network bandwidth. Therefore, many researchers have studied tile-based strategies for segmenting 360-degree video into multiple tiles through the Field of View (FoV), encoding the tiles within the FoV at high quality, and encoding or discarding the remaining tiles at low quality to reduce bitrate during encoding [9].

6DoF video, also known as volumetric video, allows for translation in horizontal, vertical, and depth directions in addition to the orientation provided by 3DoF, offering a more immersive experience for users. There are two formats for implementing 6DoF video: Multiview Video plus Depth (MVD) [10] and Point Cloud (PtCl) [11]. The MVD format encodes each view captured by the cameras individually before synthesizing them. This process can lead to significant bitrate wastage due to the large amount of redundant content between views. To address this, the MPEG Immersive Video (MIV) standard has been developed by MPEG to automatically select reference views, ensuring optimal quality rendering and significantly reducing data bitrate [12]. Additionally, the standard compresses all trimmed views into atlases, which substantially decreases the number of required encoders and decoders [13]. As a result, any conventional 2D video encoder can encode these atlases [14]. MIV operates in two modes: MIV View mode and MIV Atlas mode. MIV View mode selects more base views to preserve scene details, making it ideal for applications that demand high video quality. In contrast, MIV Atlas mode trims views to include only specific ones, thereby reducing data volume and improving transmission efficiency [15,16].

The other 6DoF format is PtCl video. A typical dynamic PtCl for entertainment purposes usually contains about 1 million points per frame, with an uncompressed bandwidth requirement of 3.6 Gbps for 30 frames per second [17]. The number and density of objects in a PtCl scene also affect the bandwidth requirements for PtCl video. PtCl can be projected onto a 2D plane and encoded by traditional video codecs like AVC or VVC, such as in Video-based PtCl Compression (V-PCC) [18,19]. This approach results in a bitstream rate much lower than 3D-based methods. Geometric 3D compression methods, such as Geometry-based PtCl Compression (G-PCC) [20], directly compress PtCl using the characteristics of octree structures. These methods offer high encoding speed but lower compression efficiency, making them suitable for PtCl live video [21]. Shi et al. [22] simplified PtCl by downsampling and resizing during the encoding phase, reconstructing them on the user side upon transmission. Han et al. [23] conditionally transmitted PtCl based on the FoV, either sending the PtCl around the FoV or adjusting the PtCl density, effectively reducing bandwidth requirements. Li et al. [24] divided PtCl into multiple volumetric tiles similar to 360-degree video, implementing transmission allocation schemes for these tiles.

With the ongoing advancement of Intelligent Transportation Systems (ITS) [25], an increasing number of autonomous vehicles are replacing today’s manually driven vehicles. These autonomous vehicles connect with each other and with surrounding roadside units (RSUs), forming vehicular networks, and engage in vehicle-to-infrastructure (V2I) and vehicle-to-vehicle (V2V) communications [26], collectively known as Vehicle-to-Everything (V2X). These extensive connectivity demands, along with in-vehicle multimedia entertainment services, present significant challenges to current wireless network communications.

In recent years, academia and industry have been increasingly focusing on sixth-generation (6G) systems to meet the future information and communications technology demands anticipated by 2030 [27,28]. Light Fidelity (LiFi), based on visible light communications (VLC), is expected to become an indispensable part of 6G systems [29]. With the rising number of mobile devices and the increasing demand for data-intensive applications and multimedia materials (e.g., audio, online gaming, images, video streaming, etc.), LiFi technology is suggested as a potential solution to the spectrum scarcity issue [30]. LiFi operates by controlling light-emitting diodes (LEDs) to generate communication signals. Its transmission is highly efficient due to the unregulated and large bandwidth of visible light. Furthermore, thanks to the use of the visible light band, LiFi is virtually immune to interference from other devices and ensures secure data transmission [31]. Jamuna et al. [32] introduce a design and prototype of a device that utilizes Li-Fi technology for vehicular communication. This device enables secure, efficient, environmentally friendly, and high-speed data transfer. Saravanan et al. [33] examine Li-Fi technology, which utilizes light-emitting diodes as the transmission module. The study explores the characteristics, communication methods, and key system technologies for high-speed data transmission, subsequently applying these in V2V communication.

Additionally, 6G will incorporate a range of emerging communication technologies, such as millimeter-wave (mmWave) and Terahertz (THz) wireless communication. These technologies benefit from their short wavelengths, allowing for significant spatial reuse and enabling higher bandwidth and transmission rates. Researchers like Su et al. [34] addressed content distribution scheduling issues in mmWave vehicular networks, while Lin et al. [35] focused on low-complexity vehicle tracking and resource allocation methods for THz V2I communications in vehicular networks. Lin et al. [36] studied the joint caching and scheduling strategy in 6G vehicular networks, enhancing request hit probability and the number of concurrent transmissions.

However, in traditional cellular networks, signal strength and inter-cell interference severely limit the performance at cell edges, which has always been a major bottleneck for any mobile network. Recently, cell-free (CF) systems have attracted increasing research attention and demonstrated their strong potential in mobile communications. CF systems deploy a considerable number of geographically distributed antenna access points. These access points are connected to a wireless access point control unit via high-speed optical fiber or wireless backhaul/fronthaul links. The wireless access point control unit operates all antenna access points as a whole without cell boundaries, using spatial multiplexing technology to serve all users on the same time–frequency resources. This technology allows vehicles to continuously enjoy network services while moving, avoiding the additional overhead of frequent handovers [37]. Zhao et al. [38] studied the scheduling of communication and computing resources in the mmWave cell-free downlink transmission architecture of urban vehicular networks, improving the performance of low-latency data transmission. As a natural evolution of contemporary large-scale multiple-input multiple-output (MIMO) technology, Extremely Large-Scale MIMO (XL-MIMO) further increases the number of antennas by at least an order of magnitude, thereby unprecedentedly improving the spectral efficiency and spatial resolution of wireless communication and sensing. Consequently, XL-MIMO is considered a key technology for 6G to meet several stringent KPIs, such as peak data rates, spectral efficiency, reliability, and precision in positioning and sensing [39]. Liu et al. [40] studied CF XL-MIMO systems with base stations equipped with XL-MIMO panels in dynamic environments, providing dynamic strategies to address high-dimensional signal processing challenges.

As autonomous driving technology advances, passengers in vehicles will have the opportunity to engage in a broader range of entertainment activities while on the move. This evolution in video applications is expected to significantly increase the demand for bandwidth within vehicular networks, potentially leading to bandwidth shortages, especially in congested traffic areas. To address this challenge, this paper presents a method for bandwidth allocation for vehicle video applications within the framework of V2X networks. The main contributions of this study are as follows:

• This study employs THz and mmWave frequency band technologies, while also introducing CF XL-MIMO systems to further enhance system coverage, providing efficient and stable bandwidth for constructing a comprehensive vehicular network environment for vehicle passengers.
• This study adopts different encoding technologies for various types of multimedia applications and dynamically adjusts video quality based on different network conditions to optimize video transmission efficiency.
• In planning bandwidth allocation, the characteristics of applications and user levels are considered, with bandwidth being prioritized for real-time applications. When similar applications compete for bandwidth, premium users are given priority access. Additionally, when network bandwidth is insufficient, V2V communication technology can be utilized to access bandwidth from non-busy road sections, thereby effectively improving the overall utilization of bandwidth resources.

2. Bandwidth Allocation for Diverse Streaming Services in V2X Communication

In this study, each RSU on the road segment coordinates the allocation of bandwidth. We utilize mmWave and THz bands to provide bandwidth for vehicular multimedia applications. Furthermore, our architecture incorporates a CF XL-MIMO system to improve communication reliability and transmission rates, as depicted in Figure 1.

We consider various types of videos, including traditional 2D video, 360-degree video, and 6DoF video. Both real-time and non-real-time application scenarios are addressed, such as live video and video on demand (VoD). To cater to diverse user needs, we classify users into premium and regular categories. Premium users, through a fee-based model, receive enhanced video quality, featuring higher resolution, lower latency, and a more immersive viewing experience. Regular users have access to standard quality basic services.

Advanced encoding technologies are employed to optimize video quality and transmission efficiency across different types of video content and application scenarios. For 2D and 360-degree videos, VVC encoding technology is used for non-real-time applications, while AVC encoding technology is utilized for real-time applications, ensuring improved transmission efficiency while maintaining high video quality.

Emerging 6DoF video content is supported in two formats: PtCl and MVD. PtCl VoD utilizes the V-PCC encoding standard with higher compression rates to reduce bandwidth requirements. Premium users benefit from the superior quality All-Intra (AI) encoding mode, while regular users utilize the default Random Access (RA) mode. For PtCl live video, the faster G-PCC encoding standard is employed.

For MVD video format, we employ the MIV encoding standard to effectively manage multi-view and depth information. Premium users benefit from the higher-quality MIV View mode, which includes a 120-degree Field of View (FoV) to prevent quality fluctuations or stuttering in the FoV area caused by sudden head movements.

Additionally, LCEVC is implemented to reduce video complexity and required bandwidth. This technology separates the basic layer and enhancement layer, allowing RSUs to allocate bandwidth resources more flexibly. This ensures that vehicle passengers can access at least the basic layer during network congestion, thereby maintaining a satisfactory viewing experience.

Figure 2 illustrates the architecture of the bandwidth allocation algorithm. The ellipsis on the right side of the image indicates that all RSUs and vehicles contain the same corresponding modules as depicted in the diagram. Before departure, the app installed in the vehicle activates the “Route Planning and Adjustment Module for Vehicles”. This module plans the route based on the passenger’s destination and real-time traffic conditions, estimating time periods for each road segment and communicating this information to the RSUs located along the route.

When a passenger in a vehicle activates a multimedia application while on the road, the “Bandwidth Calculation Module for Vehicle Video Applications” is initiated by the app on the passenger’s vehicle. This module retrieves application requirements and specifications from the application provider’s server and sends the bandwidth demand to the RSUs along the vehicle’s route.

Upon receiving a bandwidth demand request, the corresponding RSUs process it using the “Bandwidth Assignment Coordination” module. For real-time video applications, this module strives to meet the immediate bandwidth requirements. For non-real-time applications, the “Bandwidth Allocation for Non-Real-Time Applications” module is activated. RSUs coordinate with CF XL-MIMO base stations covering the road segment to collectively provide services to vehicle passengers. During periods of network congestion, RSUs dynamically adjust bandwidth allocation based on the characteristics of each application. Real-time applications, which require immediate transmission and are highly sensitive to delays, are prioritized to prevent user dissatisfaction due to interruptions. Conversely, video segments of non-real-time applications can be pre-downloaded during less congested road sections.

Furthermore, RSUs prioritize the bandwidth needs of premium users over regular users. This means that bandwidth allocated to regular users may be reallocated to premium users to ensure superior service quality. If bandwidth demand remains unmet or if bandwidth originally assigned to regular users is reassigned to premium users, RSUs activate the “Vehicle Fleet Bandwidth Coordination“ module to establish a cooperative fleet. This module utilizes V2V communication to relay content, effectively using the remaining bandwidth in non-congested road sections.

During video application operation, the vehicle’s “Bandwidth Calculation for Vehicle Video Applications” module continuously monitors network conditions and adjusts bandwidth usage. When the vehicle traverses congested road sections with heavy network traffic, the module dynamically adjusts the video quality to decrease bandwidth demand and prevent video stuttering, thereby maintaining user satisfaction. Conversely, in non-congested road sections, the module enhances the video quality of real-time videos to ensure stable and smooth playback, providing users with an enhanced viewing experience across different network environments. For non-real-time video, segments will be preloaded as much as possible to ensure playback at the expected time frames.

2.1. Route Planning and Adjustment Module for Vehicles

Before departure, vehicle passengers use the app installed in the vehicle to activate this module, planning the shortest driving route with instant traffic updates from the cloud. The system calculates the optimal route based on current traffic conditions and historical data, aiming to reach the destination in the shortest possible time. During the journey, this module continuously monitors real-time traffic conditions and dynamically adjusts the route based on real-time changes. For instance, if a traffic accident, road construction, or other unforeseen events occur ahead, the system will immediately recalculate an alternative route to help the passenger avoid congested or hazardous road sections. Simultaneously, this module periodically estimates the travel time for subsequent segments and makes predictions based on actual driving conditions.

If the vehicle passenger changes plan, such as adding a stop or changing the destination, the system will replan the route and estimated arrival time based on the new requirements. Additionally, if the estimated time of arrival for road sections differs significantly from the original schedule, this module will recalculate the shortest driving route and arrival time, making timely adjustments as needed. To ensure that RSUs obtain the latest traffic information, this module will send updated relevant information to the RSUs along the route. This information includes the times the vehicle passes through each section and the current traffic conditions. Upon receiving this information, the RSUs will update their databases, providing other vehicles with more accurate traffic information and road condition forecasts.

The execution steps of this module are as follows:

Step 1:

Before the vehicle departs, real-time traffic information is retrieved from the cloud. Based on the destination set by the vehicle passenger and the average travel time returned by each segment RSU, the shortest driving route is selected using the Dijkstra algorithm as follows:

$${\mathbf{R}}^{\sigma }=\left(c_1^{\sigma },c_2^{\sigma },\cdots ,c_{h^{\sigma }-1}^{\sigma },c_{h^{\sigma }}^{\sigma }\right),$$

(1)

where $c_1^{\sigma }$ and $c_{h^{\sigma }}^{\sigma }$ represent the starting point and the final destination of the driving route for vehicle σ, respectively.

Step 2:

The following equations are used to calculate the time for the vehicle to arrive at each road section and transmit the estimated time to the RSU along the route:

$$r{t}_{c_{i+1}^{\sigma }}=r{t}_{c_i^{\sigma }}+R{D}_{c_i^{\sigma },c_{i+1}^{\sigma }}\left(r{t}_{c_i^{\sigma }}\right)+I{D}_{c_i^{\sigma },c_{i+1}^{\sigma }}\left(r{t}_{c_i^{\sigma }}\right), 1\le i<h^{\sigma } ,$$

(2)

$$r{t}_{c_1^{\sigma }}=CurTime$$

(3)

where $c_i^{\sigma }$ represents the i-th intersection that vehicle σ passes through, and $CurTime$ is the current time. $R{D}_{c_i^{\sigma },c_{i+1}^{\sigma }}\left(r{t}_{c_i^{\sigma }}\right)$ denotes the time it takes for the vehicle to pass through the segment connecting $c_i^{\sigma }$ and $c_{i+1}^{\sigma }$ after arriving at road section $c_i^{\sigma }$ at time $r{t}_{c_i^{\sigma }}$, while $I{D}_{c_i^{\sigma },c_{i+1}^{\sigma }}\left(r{t}_{c_i^{\sigma }}\right)$ stands for the time spent by the vehicle due to traffic control before entering the segment connecting $c_i^{\sigma }$ and $c_{i+1}^{\sigma }$ after arriving at road section $c_i^{\sigma }$ at time $r{t}_{c_i^{\sigma }}$. Here, the values of $R{D}_{c_i^{\sigma },c_{i+1}^{\sigma }}\left(·\right)$ and $I{D}_{c_i^{\sigma },c_{i+1}^{\sigma }}\left(·\right)$ are both predicted using Support Vector Regressions.

Step 3:

This module operates in the background execution mode.

Step 4:

Whenever the vehicle arrives at the next intersection on the route, correct t the pass time period for each subsequent segment as follows:

$${\widehat{rt}}_{c_{i+1}^{\sigma }}={\widehat{rt}}_{c_i^{\sigma }}+R{D}_{c_i^{\sigma },c_{i+1}^{\sigma }}\left({\widehat{rt}}_{c_i^{\sigma }}\right)+I{D}_{c_i^{\sigma },c_{i+1}^{\sigma }}\left({\widehat{rt}}_{c_i^{\sigma }}\right), 1\le i<h_i^{\sigma }$$

(4)

where $c_1^{\sigma }$ represents the current segment of the route for σ, ${\widehat{rt}}_{c_i^{\sigma }}$ denotes the time when σ arrives at intersection $c_i^{\sigma }$. $R{D}_{c_i^{\sigma },c_{i+1}^{\sigma }}\left({\widehat{rt}}_{c_i^{\sigma }}\right)$ stands for the time it takes for σ to pass through the segment connecting $c_i^{\sigma }$ and $c_{i+1}^{\sigma }$ after arriving at intersection $c_i^{\sigma }$ at time ${\widehat{rt}}_{c_i^{\sigma }}$, while $I{D}_{c_i^{\sigma },c_{i+1}^{\sigma }}\left({\widehat{rt}}_{c_i^{\sigma }}\right)$ represents the time spent by the vehicle due to traffic control before entering the segment connecting $c_i^{\sigma }$ and $c_{i+1}^{\sigma }$ after arriving at intersection $c_i^{\sigma }$ at time ${\widehat{rt}}_{c_i^{\sigma }}$.

Step 5:

After transmitting the corrected arrival times at each intersection to the management RSUs of each segment, return to Step 3 to continue execution.

Step 6:

If the vehicle passenger changes the itinerary temporarily, recalculate the shortest driving route using the Dijkstra algorithm as follows:

$${\widehat{R}}^{\sigma }=\left({\widehat{c}}_1^{\sigma },{\widehat{c}}_2^{\sigma },\cdots ,{\widehat{c}}_{{\widehat{h}}^{\sigma }-1}^{\sigma },{\widehat{c}}_{{\widehat{h}}^{\sigma }}^{\sigma }\right),$$

(5)

$$r{t}_{{\widehat{c}}_{i+1}^{\sigma }}=r{t}_{{\widehat{c}}_i^{\sigma }}+R{D}_{{\widehat{c}}_i^{\sigma },{\widehat{c}}_{i+1}^{\sigma }}\left(r{t}_{{\widehat{c}}_i^{\sigma }}\right)+I{D}_{{\widehat{c}}_i^{\sigma },{\widehat{c}}_{i+1}^{\sigma }}\left(r{t}_{{\widehat{c}}_i^{\sigma }}\right), 1\le i<{\widehat{h}}^{\sigma },$$

(6)

$$r{t}_{{\widehat{c}}_1^{\sigma }}=CurTime+R{D}_{c_j^{\sigma }}\left(r{t}_{c_j^{\sigma }}\right)·\frac{rr{l}_{c_j^{\sigma },c_{j+1}^{\sigma }}}{r{l}_{c_j^{\sigma },c_{j+1}^{\sigma }}}, 1\le j<h^{\sigma },$$

(7)

$${\widehat{c}}_1^{\sigma }=c_{j+1}^{\sigma }, 1\le j<h^{\sigma },$$

(8)

where ${\widehat{c}}_1^{\sigma }$ and ${\widehat{c}}_{{\widehat{h}}^{\sigma }}^{\sigma }$ represent the next intersection and the destination of EV σ‘s current driving route, respectively, and $c_j^{\sigma }$ is the index value of the previous intersection of the current segment. $r{l}_{c_{j,j+1}^{\sigma }}$ and $rr{l}_{c_{j,j+1}^{\sigma }}$ denote the length of the current segment and the distance from σ‘s current position to the next intersection, respectively.

Return to Step 2 to continue execution.

2.2. Bandwidth Calculation Module for Vehicle Video Applications

Once the vehicle passenger initiates the video streaming application, this module will obtain the video requirements and specifications from the application software provider’s server based on the preset video quality. For VR applications such as 360-degree video and 6DoF video, the vehicle uploads the head motion trajectory from the user’s historical database to the server. This allows the software provider to predict the FoV of the requested video and return the requirements and specifications for the base layer and enhancement layer of the video. Notably, since the G-PCC encoder directly compresses 3D PtCl and cannot be enhanced using LCEVC technology, the server returns the video requirements and specifications without enhancing it into the base layer and enhancement layer if the video application type is a 6DoF PtCl real-time application.

The execution steps of this module are as follows:

Step 1:

When the vehicle passenger initiates the video streaming application, this module retrieves the video specifications from the video streaming application software provider’s server. If the video type is a VR application, the user’s historical head motion trajectory is uploaded to the server. This allows the server to predict the FoV and return the specifications required for the requested video’s base layer and enhancement layer.

Step 2:

The estimated arrival times at each section of the route, along with the video application requirements and specifications, are uploaded to the RSUs along the route. Subsequently, this module requests the governing RSU over the current road segment to activate its “Bandwidth Assignment Coordination” module and awaits the results.

Step 3:

If the results received in the previous step indicate that the required bandwidth can be satisfied, proceed to the next step. Otherwise, proceed to Step 9 accordingly.

Step 4:

If the video quality adjustments have reached the system-set limit, proceed to Step 10; otherwise, continue with the execution.

Step 5:

If the video application type is not 6DoF PtCl video, or if the system has reached its maximum allowable quantity of 6DoF PtCl videos, proceed to Step 8. Otherwise, continue with the execution.

Step 6:

If the 6DoF PtCl video is live video, increase the point density in the user’s video according to the following equation and return to Step 2. Otherwise, continue to the next step.

$$up{c}_{t_j^{\sigma ,v}}^R=\{\begin{array}{cc}p{c}_{p{l}^{\sigma ,v}+1}^R& if urs{u}_{t_j^{\sigma ,v}}>0, p{l}^{\sigma ,v}\le {\overline{pl}}^v, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ {\overline{pl}}^v& \mathrm{others}\end{array}$$

(9)

$$dp{c}_{t_j^{\sigma ,v}}^R=\{\begin{array}{cc}p{c}_{p{l}^{\sigma ,v}+1}^R& if drs{u}_{t_j^{\sigma ,v}}>0, p{l}^{\sigma ,v}\le {\overline{pl}}^v, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ {\overline{pl}}^v& \mathrm{others}\end{array}$$

(10)

where $up{c}_{t_j^{\sigma ,v}}^R$ and $dp{c}_{t_j^{\sigma ,v}}^R$ represent the point density uploaded and downloaded for 6DoF live video by vehicle passenger σ at time $t_j^{\sigma ,v}$, respectively. $urs{u}_{t_j^{\sigma ,v}}$ and $drs{u}_{t_j^{\sigma ,v}}$ respectively stand for the management RSUs where the upload and download bandwidths are insufficient for vehicle σ during the period of passing through the segment connecting $c_i^{\sigma }$ and $c_{i+1}^{\sigma }$. $t_1^{\sigma ,v}$ and $t_{e^{\sigma ,v}}^{\sigma ,v}$ denote the current and ending times of $v$, respectively. $c_i^{\sigma }$ and $c_{h^{\sigma }}^{\sigma }$ are the index values of the i-th intersection and the destination of the driving route. ${\overline{pl}}^v$ represents the system-set maximum point density for vehicle passengers, while $p{c}_{p{l}^{\sigma ,v}}^R$ is the required point density for the video set by the vehicle passenger with the level set to $p{l}^{\sigma ,v}$.

Step 7:

Increase the point density of VoD PtCl for the user according to the following equation, then return to Step 2.

$$up{c}_{t_j^{\sigma ,v}}^B=\{\begin{array}{cc}p{c}_{p{l}^{\sigma ,v}+1}^B& if urs{u}_{t_j^{\sigma ,v}}>0, p{l}^{\sigma ,v}\le {\overline{pl}}^v, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ {\overline{pl}}^v& \mathrm{others}\end{array}$$

(11)

$$dp{c}_{t_j^{\sigma ,v}}^B=\{\begin{array}{cc}p{c}_{p{l}^{\sigma ,v}+1}^B& if drs{u}_{t_j^{\sigma ,v}}>0, p{l}^{\sigma ,v}\le {\overline{pl}}^v, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ {\overline{pl}}^v& \mathrm{others}\end{array}$$

(12)

$$up{c}_{t_j^{\sigma ,v}}^E=\{\begin{array}{cc}p{c}_{p{l}^{\sigma ,v}+1}^E& if urs{u}_{t_j^{\sigma ,v}}>0, p{l}^{\sigma ,v}\le {\overline{pl}}^v, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ {\overline{pl}}^v& \mathrm{others}\end{array}$$

(13)

$$dp{c}_{t_j^{\sigma ,v}}^E=\{\begin{array}{cc}p{c}_{p{l}^{\sigma ,v}+1}^E& if drs{u}_{t_j^{\sigma ,v}}>0, p{l}^{\sigma ,v}\le {\overline{pl}}^v, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ {\overline{pl}}^v& \mathrm{others}\end{array}$$

(14)

where $up{c}_{t_j^{\sigma ,v}}^B$ and $up{c}_{t_j^{\sigma ,v}}^E$ represent the resolution of the base layer and enhancement layer PtCl uploaded for 6DoF VoD by the vehicle passenger, respectively. Similarly, $dp{c}_{t_j^{\sigma ,v}}^B$ and $dp{c}_{t_j^{\sigma ,v}}^E$ denote the resolution of the base layer and enhancement layer PtCl downloaded for 6DoF VoD, respectively. ${\overline{vl}}^v$ represents the system-set maximum resolution for video of vehicle passengers, while $v{l}_{{\sigma }^{\sigma ,v}}$ stands for the bandwidth requirement for video resolution as determined by the vehicle passenger, which is specified at the level specified by ${\kappa }^{\sigma ,v}$.

Step 8:

If the video resolution has not reached the system-set maximum, increase the video resolution and return to Step 2. Otherwise, proceed to Step 10.

$$uv{r}_{t_j^{\sigma ,v}}^B=\{\begin{array}{cc}v{l}_{{\sigma }^{\sigma ,v}+1}^B& if urs{u}_{t_j^{\sigma ,v}}>0,{\kappa }^{\sigma ,v}\le {\overline{vl}}^v, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ {\overline{vl}}^v& \mathrm{others}\end{array}$$

(15)

$$uv{r}_{t_j^{\sigma ,v}}^E=\{\begin{array}{cc}v{l}_{{\sigma }^{\sigma ,v}+1}^E& if urs{u}_{t_j^{\sigma ,v}}>0,{\kappa }^{\sigma ,v}\le {\overline{vl}}^v, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ {\overline{vl}}^v& \mathrm{others}\end{array}$$

(16)

$$dv{r}_{t_j^{\sigma ,v}}^B=\{\begin{array}{cc}v{l}_{{\sigma }^{\sigma ,v}+1}^B& if drs{u}_{t_j^{\sigma ,v}}>0,{\kappa }^{\sigma ,v}\le {\overline{vl}}^v, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ {\overline{vl}}^v& \mathrm{others}\end{array}$$

(17)

$$dv{r}_{t_j^{\sigma ,v}}^E=\{\begin{array}{cc}v{l}_{{\sigma }^{\sigma ,v}+1}^E& if drs{u}_{t_j^{\sigma ,v}}>0,{\kappa }^{\sigma ,v}\le {\overline{vl}}^v, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ {\overline{vl}}^v& \mathrm{others}\end{array}$$

(18)

where $uv{r}_{t_j^{\sigma ,v}}^B$ and $uv{r}_{t_j^{\sigma ,v}}^E$ represent the resolution of the base layer and enhancement layer uploaded for video by the vehicle passenger, respectively. Similarly, $dv{r}_{t_j^{\sigma ,v}}^B$ and $dv{r}_{t_j^{\sigma ,v}}^E$ denote the resolution of the base layer and enhancement layer downloaded for video by the vehicle passenger, respectively. ${\overline{vl}}^v$ represents the system-set maximum resolution for video of vehicle passengers, while $v{l}_{{\kappa }^{\sigma ,v}}^E$ is the bandwidth requirement for video resolution specified at level ${\kappa }^{\sigma ,v}.$.

Step 9:

If the bandwidth demand of the application is not yet satisfied and the video resolution has not reached the system-set minimum, decrease the video resolution and return to Step 2. Otherwise, proceed to the next step.

Step 10:

Notify the vehicle passenger of the returned result. If the result indicates that the bandwidth demand can be satisfied, continue execution. If not, notify the vehicle passenger and end this module.

Step 11:

If the video application type used is non-real-time, check the download status of video segments. If all video segments for that application have been preloaded, end this module.

Step 12:

This module enters background execution mode.

When the vehicle updates the driving path or it arrives at the next road segment along its route, return to Step 2 to continue execution.

2.3. Bandwidth Assignment Coordination

Upon receiving information regarding user service levels, vehicle location, estimated time to traverse road sections, and requirements for the base and enhancement layers of the LCEVC-enhanced video application, this module will assess whether any CF XL-MIMO wireless access points can meet the bandwidth demands of the application. If suitable, the controlling CF XL-MIMO wireless access point unit will then establish an access point cluster [41] to allocate sufficient bandwidth based on the expected requirements of the application. During configuration, special attention will be given to ensuring that bandwidth for the base layer is prioritized before allocating resources to the enhancement layer, given that these layers can be transmitted separately.

If the application involves real-time video and encounters insufficient allocated bandwidth due to network congestion, this module will prompt the CF XL-MIMO access point control unit to redistribute bandwidth originally allocated to non-real-time applications. Real-time video requires continuous and sufficient bandwidth for a smooth user experience. Should bandwidth remain insufficient after reallocation, priority will be given to meeting the needs of premium users by reallocating bandwidth initially assigned to regular users.

If any applications still lack adequate bandwidth thereafter, the “Vehicle Fleet Bandwidth Coordination” module will activate. It will seek CF XL-MIMO access points in other non-congested road sections to supplement the lack of bandwidth.

The execution steps of this module are as follows:

Step 1:

After receiving the bandwidth requirements for the vehicle passengers’ application, categorize the type of video application.

Step 2:

If the application is real-time video, continue to the next step. Otherwise, activate the “Bandwidth Allocation for Non-Real-Time Applications” module. Then conclude the execution of this module.

Step 3:

Based on the specifications of the live video application and the estimated time taken to traverse road sections, calculate the bandwidth required for the real-time application along the vehicle route.

Step 4:

Determine if any CF XL-MIMO access point(s) within the communication range of the vehicle can supply bandwidth for the live video application:

$$du{b}_{t_j^{\sigma ,v}}={\beta }^{\sigma ,v}·\left[{\displaystyle \sum }_{{\vartheta }^{\sigma ,v}}u{b}_{t_j^{\sigma ,v}}^{{\vartheta }^{\sigma ,v}}-\left(1-{\psi }^{\sigma ,v}\right)·\left(uv{r}_{t_j^{\sigma ,v}}^B+{\partial }^{\sigma ,v}·uv{r}_{t_j^{\sigma ,v}}^E\right)·{\mathrm{fr}}^{\sigma ,v}-{\psi }^{\sigma ,v}·up{c}_{t_j^{\sigma ,v}}·{\mathrm{fr}}^{\sigma ,v}\right], 1\le j\le e^{\sigma ,v}$$

(19)

$$urs{u}_{t_j^{\sigma ,v}}=\{\begin{array}{cc}rs{u}_{c_i^{\sigma }}& if du{b}_{t_j^{\sigma ,v}}<0, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ 0& \mathrm{others}\end{array}$$

(20)

$$dd{b}_{t_j^{\sigma ,v}}={\displaystyle \sum }_{{\vartheta }^{\sigma ,v}}d{b}_{t_j^{\sigma ,v}}^{{\vartheta }^{\sigma ,v}}-\left(1-{\psi }^{\sigma ,v}\right)·\left(dv{r}_{t_j^{\sigma ,v}}^B+{\partial }^{\sigma ,v}·dv{r}_{t_j^{\sigma ,v}}^E\right)·{\mathrm{fr}}^{\sigma ,v}-{\psi }^{\sigma ,v}·dp{c}_{t_j^{\sigma ,v}}·{\mathrm{fr}}^{\sigma ,v}, 1\le j\le e^{\sigma ,v}$$

(21)

$$drs{u}_{t_j^{\sigma ,v}}=\{\begin{array}{cc}rs{u}_{c_i^{\sigma }}& if dd{b}_{t_j^{\sigma ,v}}<0, r{t}_{c_i^{\sigma }}\le t_j^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, 1\le j\le e^{\sigma ,v},1\le i<h^{\sigma }\\ 0& \mathrm{others}\end{array}$$

(22)

$$up{c}_{t_j^{\sigma ,v}}=dp{c}_{t_j^{\sigma ,v}}=p{c}_{p{l}^{\sigma ,v}},1\le j<e^{\sigma ,v},1\le p{l}^{\sigma ,v}\le {\overline{pl}}^v$$

(23)

$$uv{r}_{t_j^{\sigma ,v}}=dv{r}_{t_j^{\sigma ,v}}=v{l}_{{\kappa }^{\sigma ,v}},1\le j<e^{\sigma ,v},1\le {\kappa }^{\sigma ,v}\le {\overline{vl}}^v$$

(24)

$$t_{j+1}^{\sigma ,v}=t_j^{\sigma ,v}+∆,1\le j<e^{\sigma ,v}$$

(25)

$$a{t}_{p_1^{\sigma }}\le t_1^{\sigma ,v}\le t_{e^{\sigma ,v}}^{\sigma ,v}\le a{t}_{p_{h^{\sigma }}^{\sigma }}$$

(26)

where the binary flag ${\beta }^{\sigma ,v}=1$ indicates that real-time application $v$ is bidirectional, while ${\beta }^{\sigma ,v}=0$ indicates it is unidirectional. Binary indicator ${\psi }^{\sigma ,v}=1$ signifies $v$ as a 6DoF PtCl application, while binary indicator ${\partial }^{\sigma ,v}=1$ indicates that the encoding of $v$ also includes the enhancement layer. $t_1^{\sigma ,v}$ and $t_{e^{\sigma ,v}}^{\sigma ,v}$ denote the current and end times of $v$, respectively, while $c_i^{\sigma }$ and $c_{h^{\sigma }}^{\sigma }$ represent the indices of the ith intersection and the destination along the driving route, respectively. $u{b}_{t_j^{\sigma ,v}}^{{\vartheta }^{\sigma ,v}}$ and $d{b}_{t_j^{\sigma ,v}}^{{\vartheta }^{\sigma ,v}}$ respectively stand for the upload and download bandwidth that the vehicle can be allocated for bidirectional video $v$ when passing through the transmission range of CF XL-MIMO access point ${\vartheta }^{\sigma ,v}$ at time slot $t_j^{\sigma ,v}$. $up{c}_{t_j^{\sigma ,v}}$ and $dp{c}_{t_j^{\sigma ,v}}$ denote the point density uploaded and downloaded for 6DoF PtCl video $v$, respectively; $uv{r}_{t_j^{\sigma ,v}}^B$ and $dv{r}_{t_j^{\sigma ,v}}^B$ represent the resolution of the uploaded and downloaded video base layer for $v$, respectively, $uv{r}_{t_j^{\sigma ,v}}^E$ and $dv{r}_{t_j^{\sigma ,v}}^E$ stand for the uploaded and downloaded enhancement layer, respectively, while ${\mathrm{fr}}^{\sigma ,v}$ denotes the designated frame rate per second. $rs{u}_{c_i^{\sigma }}$ represents the index value of the management RSU when the vehicle passes through segment $c_i^{\sigma }$. When the values of $du{b}_{t_j^{\sigma ,v}}$ and $dd{b}_{t_j^{\sigma ,v}}$ are less than zero, it indicates that the upload or download bandwidth provided by CF XL-MIMO access point(s) for segment $c_i^{\sigma }$ cannot meet the minimum bandwidth requirement of $v$; at this time, $urs{u}_{t_j^{\sigma ,v}}$ and $ddrs{u}_{t_j^{\sigma ,v}}$ are respectively used to indicate the management RSU of the vehicle passing through the segment $c_i^{\sigma }$ where the upload and download bandwidth is insufficient at time slot $t_j^{\sigma ,v}$. The number of PtCl for 6DoF PtCl video can be divided into ${\overline{pl}}^v$ levels, which is also the upper limit of the system-set point density video for vehicle passengers, while $p{c}_{p{l}^{\sigma ,v}}$ sets the video streaming screen resolution requirement at level $p{l}^{\sigma ,v}$ for vehicle passengers. The upper limit level of the resolution of video streaming screens for other categories of videos is ${\overline{vl}}^v$, and $v{l}_{{\kappa }^{\sigma ,v}}$ is the resolution requirement of video streaming screens set by vehicle passengers at level ${\kappa }^{\sigma ,v}$.

Step 5:

If the bandwidth requirements of the video can be met, notify the CF XL-MIMO access point control unit to provide the bandwidth vehicle passengers expected, and then return the results to the vehicle passenger. The execution of this module ends.

If not, continue.

Step 6:

To meet the bandwidth requirements of real-time applications, the module reallocates the bandwidth currently assigned to non-real-time applications during the same time slot. In order to address any remaining bandwidth deficit for non-real-time applications after this adjustment, the ‘Bandwidth Allocation for Non-Real-Time Applications’ module will subsequently be activated.

$$bu{n}_{t_j^{\sigma ,v}}=\{\begin{array}{cc}{\displaystyle \sum _{\mu }}{\displaystyle \sum _{{\theta }^{\mu }}}u{b}_{t_j^{\sigma ,v}}^{{\theta }^{\mu }}& \mathrm{if} du{b}_{t_j^{\sigma ,v}}<0\\ 0& \mathrm{others}\end{array},1\le j\le e^{\sigma ,v}$$

(27)

$$du{b}_{t_j^{\sigma ,v}}=du{b}_{t_j^{\sigma ,v}}+bu{n}_{t_j^{\sigma ,v}}$$

(28)

$$bd{n}_{t_j^{\sigma ,v}}=\{\begin{array}{cc}{\displaystyle \sum _{\mu }}{\displaystyle \sum _{{\theta }^{\mu }}}d{b}_{t_j^{\sigma ,v}}^{{\theta }^{\mu }}& \mathrm{if} dd{b}_{t_j^{\sigma ,v}}<0,\\ 0& \mathrm{others}\end{array} ,1\le j\le e^{\sigma ,v}$$

(29)

$$dd{b}_{t_j^{\sigma ,v}}=dd{b}_{t_j^{\sigma ,v}}+bd{n}_{t_j^{\sigma ,v}}$$

(30)

where $\mu$ is the index value of a non-real-time application, ${\theta }^{\mu }$ represents the CF XL-MIMO access point that originally allocated bandwidth to $\mu$. $bu{n}_{t_j^{\sigma ,v}}$ and $bd{n}_{t_j^{\sigma ,v}}$ denote the upload and download bandwidth that can be reassigned from $\mu$ to real-time application $v$. When the updated values of $du{b}_{t_j^{\sigma ,v}}$ and $dd{b}_{t_j^{\sigma ,v}}$ are less than zero, it indicates that the bandwidth reassigned from $\mu$ to $v$ still cannot meet the bandwidth requirements of $v$.

Step 7:

If the expected bandwidth of the real-time application $v$ has been met, notify the vehicle passenger and end the execution of this module; otherwise, continue to the next step.

Step 8:

If the passenger is a premium user, proceed to the next step; otherwise, skip to step 12.

Step 9:

Allocate the bandwidth beyond the minimum required for real-time applications of regular users to real-time applications for premium users.

$$bu{r}_{t_j^{\sigma ,v}}=\{\begin{array}{cc}{\displaystyle \sum _{\varsigma }}{\displaystyle \sum _{{\theta }^{\varsigma }}}u{b}_{t_j^{\sigma ,v}}^{{\theta }^{\varsigma }}& \mathrm{if} du{b}_{t_j^{\sigma ,v}}<0\\ 0& \mathrm{others}\end{array},1\le j\le e^{\sigma ,v}$$

(31)

$$du{b}_{t_j^{\sigma ,v}}=du{b}_{t_j^{\sigma ,v}}+bu{r}_{t_j^{\sigma ,v}}$$

(32)

$$bd{r}_{t_j^{\sigma ,v}}=\{\begin{array}{cc}{\displaystyle \sum _{\varsigma }}{\displaystyle \sum _{{\theta }^{\varsigma }}}d{b}_{t_j^{\sigma ,v}}^{{\theta }^{\sigma }}& \mathrm{if} dd{b}_{t_j^{\sigma ,v}}<0,\\ 0& \mathrm{others}\end{array} ,1\le j\le e^{\sigma ,v}$$

(33)

$$dd{b}_{t_j^{\sigma ,v}}=dd{b}_{t_j^{\sigma ,v}}+bd{r}_{t_j^{\sigma ,v}}$$

(34)

where ς is the index value representing a real-time application of a regular user, ${\theta }^{\varsigma }$ represents the CF XL-MIMO access point that originally allocated bandwidth to ς. $bu{r}_{t_j^{\sigma ,v}}$ and $bd{r}_{t_j^{\sigma ,v}}$ denote the upload and download bandwidth that can be reassigned from ς to $v$, respectively. When the updated values of $du{b}_{t_j^{\sigma ,v}}$ and $dd{b}_{t_j^{\sigma ,v}}$ are less than zero, it indicates that the bandwidth reassigned from ς to $v$ still cannot meet the requirements of $v$.

Step 10:

If the previous step shows that either $bu{r}_{t_j^{\sigma ,v}}$ or $bd{r}_{t_j^{\sigma ,v}}$ is greater than zero, it indicates that part of the bandwidth for a regular user’s real-time application ς has been reassigned to the premium user. In this case, initiate the “Vehicle Fleet Bandwidth Coordination” module to reallocate bandwidth for ς.

Step 11:

At this stage, if both $du{b}_{t_j^{\sigma ,v}}$ and $dd{b}_{t_j^{\sigma ,v}}$ are zero, it means that the expected bandwidth requirement of the requested application has been met. Notify the vehicle passenger and end the execution of this module. Otherwise, proceed to the next step.

Step 12:

Activate the “Vehicle Fleet Bandwidth Coordination” module to identify CF XL-MIMO access points in less congested road sections that can allocate bandwidth for application $v$.

Step 13:

Notify the vehicle passenger of the results and end the execution of this module.

2.4. Bandwidth Allocation for Non-Real-Time Applications

Since the video content of a non-real-time application is stored on the servers of application software providers, video segments can be pre-downloaded to the memory of the requesting passenger’s vehicle when bandwidth is abundant. This module adjusts the ratio of pre-downloaded video segments based on the remaining travel time and network conditions, and inversely adjusts according to the proportion of remaining segments stored in the vehicle. When the network is uncongested, RSUs can allocate more bandwidth to pre-download additional segments for the passenger’s later viewing. This approach helps avoid yielding bandwidth to real-time applications in congested road segments and prevents service interruptions or quality degradation of non-real-time videos. Conversely, when the network is crowded, this module reduces the number of pre-downloaded segments to free up bandwidth for serving more users.

The execution steps of this module are as follows:

Step 1:

Considering the specifications of the base and enhancement layers of the non-real-time video, network conditions, the remaining travel time of the vehicle, and the number of remaining segments stored in the vehicle’s memory, the bandwidth allocated to the non-real-time application v for the remaining route can be calculated as follows:

$$\mathrm{Max}\left({\overline{s}}^{\sigma ,v}\right),$$

(35)

subject to:

$${\delta }_{{\tau }_s^{\sigma ,v}}·\Delta ·{\displaystyle \sum }_{{\vartheta }^{\sigma }}d{b}_{{\tau }_s^{\sigma ,v}}^{{\vartheta }^{\sigma ,v}}\ge s{l}_s^{\sigma ,v}·\left(dv{r}_{{\tau }_s^{\sigma ,v}}^B+dv{r}_{{\tau }_s^{\sigma ,v}}^E\right)·{\mathrm{fr}}^{\sigma ,v}, 1\le {\delta }_{{\tau }_s^{\sigma ,v}}, i{s}^{\sigma ,v}\le s\le {\overline{s}}^{\sigma ,v},$$

(36)

$$1\le i{s}^{\sigma ,v}\le {\overline{s}}^{\sigma ,v}\le {\mathrm{S}}^{\sigma ,v},$$

(37)

$${\tau }_1^{\sigma ,v}=sp{t}^{\sigma ,v},$$

(38)

$$r{t}_{c_1^{\sigma }}<sp{t}^{\sigma ,v}<ep{t}^{\sigma ,v}\le r{t}_{c_{h^{\sigma }}^{\sigma }},$$

(39)

$$CurTime<{\tau }_{i{s}^{\sigma ,v}}^{\sigma ,v},$$

(40)

$$ep{t}^{\sigma ,v}\le r{t}_{c_{h^{\sigma }}^{\sigma }}\le CurTime+{\displaystyle \sum }_{s=i{s}^{\sigma ,v}}^{{\overline{s}}^{\sigma ,v}}s{l}_s^{\sigma ,v},$$

(41)

$$sp{t}^{\sigma ,v}\le {\tau }_s^{\sigma ,v}<{\tau }_s^{\sigma ,v}+{\delta }_{{\tau }_s^{\sigma ,v}}·\Delta <ep{t}^{\sigma ,v}, i{s}^{\sigma ,v}\le s\le {\overline{s}}^{\sigma ,v},$$

(42)

$$r{t}_{c_i^{\sigma }}\le {\tau }_s^{\sigma ,v}\le r{t}_{c_{i+1}^{\sigma }}, \mathrm{if} {\rho }_{c_i^{\sigma },c_{i+1}^{\sigma }}\le \underset{\_}{\mathsf{\rho }}, 1\le i<h^{\sigma }$$

(43)

$$dv{r}_{{\tau }_s^{\sigma ,v}}^B=dv{r}_{{\tau }_s^{\sigma ,v}}^E=v{l}_{{\sigma }^{\sigma ,v}}, i{s}^{\sigma ,v}\le s\le {\overline{s}}^{\sigma ,v},$$

(44)

$$bu{f}^{\sigma ,v}=bu{f}^{\sigma ,v}+{\displaystyle \sum }_{s=i{s}^{\sigma ,v}}^{{\overline{s}}^{\sigma ,v}}\left[s{l}_s^{\sigma ,v}·\left(dv{r}_{{\tau }_s^{\sigma ,v}}^B+dv{r}_{{\tau }_s^{\sigma ,v}}^E\right)·{\mathrm{fr}}^{\sigma ,v}\right],$$

(45)

where ${\overline{s}}^{\sigma ,v}$ represents the number of video segments of $v$ that this module allows pre-downloading, ${\tau }_s^{\sigma ,v}$ is the time for pre-downloading video segment s of non-real-time application $v$, ${\mathrm{S}}^{\sigma ,v}$ denotes the total number of video segments for $v$, and $i{s}^{\sigma ,v}$ stands for the index of the first video segment that has not been downloaded yet. $d{b}_{{\tau }_s^{\sigma ,v}}^{{\vartheta }^{\sigma ,v}}$ is the bandwidth provided by the CF XL-MIMO access point ${\vartheta }^{\sigma ,v}$ for pre-downloading $v$ during time ${\tau }_s^{\sigma ,v}$ over duration $\Delta$, and ${\delta }_{{\tau }_s^{\sigma ,v}}$ is the number of time slots for consecutive downloading of video segments within the communication range of $d{b}_{{\tau }_{s^{\sigma ,v}}}^{{\vartheta }^{\sigma ,v}}$. $s{l}_s^{\sigma ,v}$ represents the time duration of downloading video segment $s$ of $v$. $dv{r}_{{\tau }_s^{\sigma ,v}}^B$ and $dv{r}_{{\tau }_s^{\sigma ,v}}^E$ indicate the resolutions of the base and enhancement layers of $v$, respectively, while ${\mathrm{fr}}^{\sigma ,v}$ denotes the frame rate per second. $CurTime$ is the current time, $sp{t}^{\sigma ,v}$ and $ep{t}^{\sigma ,v}$ stand for the start and end times of playing $v$, respectively, $\underset{\_}{\mathsf{\rho }}$ is the lower limit of traffic flow that indicates the road segment is congested, and ${\rho }_{c_i^{\sigma },c_{i+1}^{\sigma }}$ represents the traffic flow connecting road sections $c_i^{\sigma }$ and $c_{i+1}^{\sigma }$. $v{l}_{{\sigma }^{\sigma ,v}}$ is the resolution requirement for the ${\kappa }^{\sigma ,v}$ level of video screen set by the vehicle passenger, and $bu{f}^{\sigma ,v}$ represents the pre-downloaded video segments stored in the buffer.

Step 2:

Examine whether the CF XL-MIMO access points from the previous step can meet the minimum bandwidth requirements for the base and enhancement layers of $v$ as follows:

$$dp{t}^{\sigma ,v}=CurTime+{\displaystyle \sum }_{s=i{s}^{\sigma ,v}}^{{\overline{s}}^{\sigma ,v}}s{l}_s^{\sigma ,v}-r{t}_{c_{h^{\sigma }}^{\sigma }},$$

(46)

where $dp{t}^{\sigma ,v}$ is the time duration of pre-downloaded video $v$ stored in the buffer.

Step 3:

If $dp{t}^{\sigma ,v}\ge$ 0, it indicates that the required bandwidth for both the base and enhancement layers of $v$ can be pre-downloaded. In this case, the CF XL-MIMO access point control unit is notified, and the result is returned to the vehicle passenger, concluding the execution of this module. Otherwise, proceed to the next step.

Step 4:

Calculate the bandwidth available for the remaining travel distance of the non-real-time application based on the specifications of the base layer $v$:

$$\mathrm{Max}\left({\overline{s}}^{\sigma ,v}\right),$$

(47)

The above equation depends on:

$${\delta }_{{\tau }_s^{\sigma ,v}}·\Delta ·{\displaystyle \sum }_{{\vartheta }^{\sigma }}d{b}_{{\tau }_s^{\sigma ,v}}^{{\vartheta }^{\sigma ,v}}\ge s{l}_s^{\sigma ,v}·dv{r}_{{\tau }_s^{\sigma ,v}}^B·{\mathrm{fr}}^{\sigma ,v}, 1\le {\delta }_{{\tau }_s^{\sigma ,v}}, i{s}^{\sigma ,v}\le s\le {\overline{s}}^{\sigma ,v},$$

(48)

Equations (37)–(45)

Step 5:

If the previous step can meet the bandwidth requirements for the base layer of $v$, then notify the CF XL-MIMO access point control unit to provide the required bandwidth for the base layer to the vehicle, and return the result to the vehicle passenger, concluding the execution of this module. Otherwise, continue to the next step.

Step 6:

If the vehicle passenger is categorized as a regular user, proceed to Step 9.

Step 7:

Consult the RSU of the remaining road segments along the route to reallocate the bandwidth originally assigned to non-real-time applications of regular users to premium users.

$$\mathrm{Max}\left({\overline{s}}^{\sigma ,v}\right),$$

(49)

The above equation depends on:

$${\delta }_{{\tau }_s^{\sigma ,v}}·\Delta ·{\displaystyle \sum }_{{\phi }^{\mu }}d{b}_{{\tau }^{\sigma ,v}}^{{\phi }^{\mu }}\ge s{l}_s^{\sigma ,v}·dv{r}_{{\tau }_s^{\sigma ,v}}^B·{\mathrm{fr}}^{\sigma ,v}, 1\le {\delta }_{{\tau }_s^{\sigma ,v}}, i{s}^{\sigma ,v}\le s\le {\overline{s}}^{\sigma ,v},$$

(50)

Equations (37)–(45)

where $\mu$ is the index value representing the non-real-time application for regular users, and $d{b}_{{\tau }^{\sigma ,v}}^{{\phi }^{\mu }}$ is the bandwidth provided by CF XL-MIMO access point ${\phi }^{\mu }$ for pre-downloading $\mu$ at time ${\tau }^{\sigma ,v}$ over duration $\Delta$.

Step 8:

If the bandwidth obtained in the previous step meets the bandwidth requirements, return the result to the vehicle passenger, and conclude the execution of this module. Otherwise, continue to the next step.

Step 9:

Activate the “Vehicle Fleet Bandwidth Coordination” module to locate CF XL-MIMO access points on less congested road segments for non-real-time applications experiencing bandwidth deficits. Transfer bandwidth to these applications via inter-vehicle communication and notify the vehicle passenger of the outcome.

2.5. Vehicle Fleet Bandwidth Coordination

This module facilitates the formation of a vehicle fleet by connecting the requesting passenger’s vehicle with others within the V2V communication range. It alleviates bandwidth deficits for passengers needing to upload or download video content through the excess bandwidth provided by CF XL-MIMO access points located at less congested road segments. Once the fleet connection is successfully established, excess bandwidth from these CF XL-MIMO access points can be relayed to the requesting passenger’s vehicle located at the rear of the fleet.

The execution steps of this module are as follows:

Step 1:

The RSU connects the vehicle requesting bandwidth with other vehicles within the V2V communication range to form a fleet.

$$\begin{gathered} \underset{{\mathrm{F}}^{\sigma ,v}}{\arg }\mathrm{Min}\{{\gamma }^{\sigma ,v}\cdot [{\beta }^{\sigma ,v}\cdot ({\displaystyle \sum _{f=1}^{{\mathrm{F}}^{\sigma ,v}}{\displaystyle \sum _{{\varphi }^{r_{f,1}^{\sigma ,v}}}u{b}_{t_l^{\sigma ,v}}^{{\varphi }^{r_{f,1}^{\sigma ,v}}}-d{u}_{t_l^{\sigma ,v}})+(}}{\displaystyle \sum _{f=1}^{{\mathrm{F}}^{\sigma ,v}}{\displaystyle \sum _{{\varphi }^{r_{f,1}^{\sigma ,v}}}d{b}_{t_l^{\sigma ,v}}^{{\varphi }^{r_{f,1}^{\sigma ,v}}}-d{d}_{t_l^{\sigma ,v}})]}} \\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}+(1-{\gamma }^{\sigma ,v}){\displaystyle \sum _{f=1}^{{\mathrm{F}}^{\sigma ,v}}{\delta }_{{\tau }_s^{\sigma ,v}}·\Delta ·{\displaystyle \sum _{{\varphi }^{r_{f,1}^{\sigma ,v}}}d{b}_{t_l^{\sigma ,v}}^{{\varphi }^{r_{f,1}^{\sigma ,v}}}}}-s{l}_s^{\sigma ,v}\cdot dv{r}_{t_l^{\sigma ,v}}^B\cdot f{r}^{\sigma ,v}]\} \end{gathered}$$

(51)

subject to:

$${ℱ}_f^{\sigma ,v}=\left(r_{f,1}^{\sigma ,v},r_{f,2}^{\sigma ,v},\cdots ,r_{f,{\chi }_f^{\sigma ,v}-1}^{\sigma ,v},r_{f,{\chi }_f^{\sigma ,v}}^{\sigma ,v}\right), 1\le f<{\mathrm{F}}^{\sigma ,v},$$

(52)

$$r_{f,{\chi }_f^{\sigma ,v}}^{\sigma ,v}=, 1\le f<{\mathrm{F}}^{\sigma ,v},$$

(53)

$$1\le {\delta }_{{\tau }_s^{\sigma ,v}}, i{s}^{\sigma ,v}\le s\le {\overline{s}}^{\sigma ,v}, \mathrm{if}{\gamma }^{\sigma ,v}=0,$$

(54)

$${\displaystyle \sum }_{f=1}^{{\mathrm{F}}^{\sigma ,v}}{\delta }_{{\tau }_s^{\sigma ,v}}·\Delta ·{\displaystyle \sum }_{{\varphi }^{r_{f,1}^{\sigma ,v}}}d{b}_{t_l^{\sigma ,v}}^{{\varphi }^{r_{f,1}^{\sigma ,v}}}\ge s{l}_s^{\sigma ,v}·dv{r}_{t_l^{\sigma ,v}}^B·{\mathrm{fr}}^{\sigma ,v}, 1\le l\le e^{\sigma ,v}, \mathrm{if}{\gamma }^{\sigma ,v}=0,$$

(55)

$${\displaystyle \sum }_{f=1}^{{\mathrm{F}}^{\sigma ,v}}{\displaystyle \sum }_{{\varphi }^{r_{f,1}^{\sigma ,v}}}u{b}_{t_l^{\sigma ,v}}^{{\varphi }^{r_{f,1}^{\sigma ,v}}}\ge d{u}_{t_l^{\sigma ,v}}, 1\le l\le e^{\sigma ,v},r{t}_{c_k^{\sigma }}\le t_l^{\sigma ,v}<r{t}_{c_{k+1}^{\sigma }},{ \mathrm{if} \gamma }^{\sigma ,v}=1,{\beta }^{\sigma ,v}=1,$$

(56)

$${\displaystyle \sum }_{f=1}^{{\mathrm{F}}^{\sigma ,v}}{\displaystyle \sum }_{{\varphi }^{r_{f,1}^{\sigma ,v}}}d{b}_{t_l^{\sigma ,v}}^{{\varphi }^{r_{f,1}^{\sigma ,v}}}\ge d{d}_{t_l^{\sigma ,v}}, 1\le l\le e^{\sigma ,v},r{t}_{c_k^{\sigma }}\le t_l^{\sigma ,v}<r{t}_{c_{k+1}^{\sigma }}, {\mathrm{if} \gamma }^{\sigma ,v}=1,$$

(57)

$$ur{b}_{t_l^{\sigma ,v}}^{r_{f,i}^{\sigma ,v},r_{f,i+1}^{\sigma ,v}}\ge uv{b}_{t_l^{\sigma ,v}}^{r_{f,i}^{\sigma ,v},r_{f,i+1}^{\sigma ,v}}, 1\le l\le e^{\sigma ,v},1\le i<e^{\sigma ,v},1\le f\le {\mathrm{F}}_k^{\sigma ,v}, {\mathrm{if} \beta }^{\sigma ,v}=1$$

(58)

$$dr{b}_{t_l^{\sigma ,v}}^{r_{f,i}^{\sigma ,v},r_{f,i+1}^{\sigma ,v}}\ge dv{b}_{t_l^{\sigma ,v}}^{r_{f,i}^{\sigma ,v},r_{f,i+1}^{\sigma ,v}}, 1\le l\le e^{\sigma ,v},1\le i<e^{\sigma ,v},1\le f\le {\mathrm{F}}_k^{\sigma ,v},$$

(59)

$$t_{l+1}^{\sigma ,v}=t_l^{\sigma ,v}+\Delta , 1\le l\le e^{\sigma ,v}$$

(60)

where the binary flags ${\gamma }^{\sigma ,v}=1$ and ${\beta }^{\sigma ,v}=1$ indicate that the application is a real-time video and a bidirectional video, respectively. ${\mathrm{F}}^{\sigma ,v}$ is the num.er of fleets, ${ℱ}_f^{\sigma ,v}$ denotes the f-th fleet that relays bandwidth for $v$, and ${\chi }_f^{\sigma ,v}$ represents the length of ${ℱ}_f^{\sigma ,v}$. $r_{f,1}^{\sigma ,v}$ stands for the index of the vehicle at the head of the fleet, $r_{f,{\chi }_f^{\sigma ,v}}^{\sigma ,v}$ represents vehicle σ located at the end of the fleet, ${\varphi }^{r_{f,1}^{\sigma ,v}}$ represents a CF XL-MIMO access point covering the communication range of the fleet head, and $c_{h^{\sigma }}^{\sigma }$ is the destination of σ. $v$ faces bandwidth deficit when passing the k-th road segment connecting $c_k^{\sigma }$ and $c_{k+1}^{\sigma }$. $d{u}_{t_l^{\sigma ,v}}$ and $d{d}_{t_l^{\sigma ,v}}$ respectively represent the upload and download bandwidth deficits of a real-time video at time $t_l^{\sigma ,v}$ when passing through the segment, while s is the index of the road segment where non-real-time video segments cannot be pre-downloaded at time $t_l^{\sigma ,v}$. $t_1^{\sigma ,v}$ and $t_{e^{\sigma ,v}}^{\sigma ,v}$ represent the start and end playback times for $v$, respectively. $ur{b}_{t_l^{\sigma ,v}}^{r_{f,i}^{\sigma ,v},r_{f,i+1}^{\sigma ,v}}$ and $dr{b}_{t_l^{\sigma ,v}}^{r_{f,i}^{\sigma ,v},r_{f,i+1}^{\sigma ,v}}$ denote the remaining bandwidth that can be uploaded and downloaded from vehicle $r_{f,i}^{\sigma ,v}$ to $r_{f,i+1}^{\sigma ,v}$ at time $t_l^{\sigma ,v}$, respectively, while $uv{b}_{t_l^{\sigma ,v}}^{r_{f,i}^{\sigma ,v},r_{f,i+1}^{\sigma ,v}}$ and $dv{b}_{t_l^{\sigma ,v}}^{r_{f,i}^{\sigma ,v},r_{f,i+1}^{\sigma ,v}}$ represent the total bandwidth required to upload and download from vehicle $r_{f,i}^{\sigma ,v}$ to vehicle $r_{f,i+1}^{\sigma ,v}$ at time $t_l^{\sigma ,v}$, respectively.

Step 2:

If the fleet connection establishment fails, record the insufficient bandwidth for $v$ and proceed to Step 4. Otherwise, continue to execute the next step.

Step 3:

Once the fleet is formed, bandwidth is forwarded to v using V2V communication. This module evaluates whether the CF XL-MIMO access points supporting the fleet meet v’s bandwidth requirements as follows:

$$d{u}_{t_l^{\sigma ,v}}=\{\begin{array}{cc}{\displaystyle \sum _{f=1}^{{\mathrm{F}}^{\sigma ,v}}}{\displaystyle \sum _{{\varphi }^{r_{f,1}^{\sigma ,v}}}}u{b}_{t_l^{\sigma ,v}}^{{\varphi }^{r_{f,1}^{\sigma ,v}}}-d{u}_{t_l^{\sigma ,v}}& { \mathrm{if} \beta }^{\sigma ,v}=1 \&{\gamma }^{\sigma ,v}=1\\ 0& \mathrm{others}\end{array},$$

(61)

$$d{d}_{t_l^{\sigma ,v}}=\{\begin{array}{cc}{\displaystyle \sum _{f=1}^{{\mathrm{F}}^{\sigma ,v}}}{\displaystyle \sum _{{\varphi }^{r_{f,1}^{\sigma ,v}}}}d{b}_{t_l^{\sigma ,v}}^{{\varphi }^{r_{f,1}^{\sigma ,v}}}-d{d}_{t_l^{\sigma ,v}}& \mathrm{if} {\gamma }^{\sigma ,v}=1\\ 0& \mathrm{others}\end{array},$$

(62)

$$dn{r}_{t_l^{\sigma ,v}}=\{\begin{array}{cc}{\displaystyle \sum _{f=1}^{{\mathrm{F}}^{\sigma ,v}}}{\delta }_{{\tau }_s^{\sigma ,v}}·\Delta ·{\displaystyle \sum _{{\varphi }^{r_{f,1}^{\sigma ,v}}}}d{b}_{t_l^{\sigma ,v}}^{{\varphi }^{r_{f,1}^{\sigma ,v}}}-s{l}_s^{\sigma ,v}·dv{r}_{t_l^{\sigma ,v}}^B·{\mathrm{fr}}^{\sigma ,v}& \mathrm{if} {\gamma }^{\sigma ,v}=0\\ 0& \mathrm{others}\end{array},$$

(63)

where $t_j^{\sigma ,v}$ denotes the time period during which the application faces a bandwidth deficit. If $d{u}_{t_l^{\sigma ,v}}$ is negative, it indicates that the real-time application does not obtain sufficient bandwidth for uploading video at time $t_l^{\sigma ,v}$. Similarly, if $d{d}_{t_l^{\sigma ,v}}$ is negative, it signifies that the application does not obtain sufficient bandwidth for downloading video at that time. If $dn{r}_{t_l^{\sigma ,v}}$ is negative, it implies that the non-real-time video segment’s bandwidth is insufficient at that time.

Step 4:

If the fleet formed in Step 1 has successfully met the expected bandwidth for $v$ after forwarding the bandwidth, notify the vehicle passenger of the result, and this module will terminate its execution.

Otherwise, notify the vehicle passenger of the result, and this module will enter background execution mode.

At the next intersection on the vehicle’s route, it will resume at Step 1 and continue its execution.

3. Simulation Results and Discussion

In this study, the proposed algorithm was simulated on a personal computer equipped with an Intel Core i7 2.9 GHz CPU and 64 GB RAM. Historical traffic data were sourced from a website that provides traffic volume counts for New York City [42]. In-vehicle video applications are categorized into live video and VoD, including 2D video, 360-degree video, and 6DoF video. The 6DoF video format includes two types: PtCl video and MIV video. The simulated data for the aforementioned video applications were obtained from statistics on the user base of VoD and live video streaming platforms [43], estimates of market growth and share for immersive video [44], and projections of user numbers for 360-degree video and interactive immersive 6DoF video [45]. Additionally, factors such as the relative ease of producing MIV format compared to PtCl format in 6DoF video were considered in determining the counts and ratios for various applications.

Table 1. Minimum bandwidth requirements for 2D Video.

Video Type	Resolution/Frame Rate	Minimum Required Bandwidth	Bandwidth Required for Base Layer	Bandwidth Required for Enhancement Layer
VoD	1080P/30FPS	1.644 Mbps	0.987 Mbps	0.657 Mbps
	2K/30FPS	3.288 Mbps	2.304 Mbps	0.984 Mbps
	4K/30FPS	7.193 Mbps	5.036 Mbps	2.157 Mbps
	8K/30FPS	16.443 Mbps	11.511 Mbps	4.932 Mbps
Live video	720P/30FPS	2.52 Mbps	2.142 Mbps	0.378 Mbps
	1080P/30FPS	6.3 Mbps	2.52 Mbps	3.78 Mbps
	2K/30FPS	9.45 Mbps	7.56 Mbps	1.89 Mbps
	4K/30FPS	18.9 Mbps	15.12Mbps	3.78 Mbps

shows the minimum bandwidth requirements for various resolutions of 2D live video and 2D VoD [46]. Live video is encoded using AVC, while VoD is encoded using VVC, with both enhanced into a base layer and an enhancement layer through LCEVC [8,47].

Table 2. Minimum bandwidth requirements for 360-degree VoD.

User Level	Resolution/Frame Rate	Minimum Required Bandwidth	Bandwidth Required for Base Layer	Bandwidth Required for Enhancement Layer
Regular	1080P/30FPS	0.554 Mbps	0.387 Mbps	0.166 Mbps
	2K/30FPS	1.107 Mbps	0.774 Mbps	0.332 Mbps
	4K/30FPS	1.732 Mbps	1.212 Mbps	0.519 Mbps
	8K/30FPS	6.93 Mbps	4.851 Mbps	2.079 Mbps
Premium	1080P/30FPS	0.986 Mbps	0.69 Mbps	0.295 Mbps
	2K/30FPS	1.97 Mbps	1.379 Mbps	0.591 Mbps
	4K/30FPS	3.083 Mbps	2.158 Mbps	0.924 Mbps
	8K/30FPS	12.332 Mbps	8.632 Mbps	3.699 Mbps
	12K/30FPS	103.09 Mbps	72.163 Mbps	30.927 Mbps

and

Table 3. Minimum bandwidth requirements for 360-degree live video.

User Level	Resolution/Frame Rate	Minimum Required Bandwidth	Bandwidth Required for Base Layer	Bandwidth Required for Enhancement Layer
Regular	1080P/30FPS	1.699 Mbps	1.444 Mbps	0.254 Mbps
	2K/30FPS	2.124 Mbps	1.805 Mbps	0.318 Mbps
	4K/30FPS	3.398 Mbps	2.888 Mbps	0.509 Mbps
	8K/30FPS	13.595 Mbps	11.555 Mbps	2.039 Mbps
Premium	1080P/30FPS	3.024 Mbps	2.57 Mbps	0.453 Mbps
	2K/30FPS	3.78 Mbps	3.213 Mbps	0.567 Mbps
	4K/30FPS	6.048 Mbps	5.14 Mbps	0.771 Mbps
	8K/30FPS	24.192 Mbps	20.563 Mbps	3.084 Mbps
	12K/30FPS	210.924 Mbps	179.285 Mbps	31.638 Mbps

show the minimum bandwidth requirements for 360-degree VoD and 360-degree live video [48,49], respectively. For 360-degree live video, AVC encoding is used, while 360-degree VoD employs VVC encoding, both enhanced with LCEVC. The 360-degree video is segmented into multiple tiles, with tiles within the FoV range transmitted at normal resolution, and tiles outside the FoV at the lowest resolution [50]. Premium users have a 120-degree FoV setting, allowing for a broader video view, whereas regular users have the standard 90-degree FoV setting.

Table 4. Minimum bandwidth requirements for PtCl VoD.

User Level	Point Density	Minimum Required Bandwidth	Bandwidth Required for Base Layer	Bandwidth Required for Enhancement Layer
Regular	Low	4.545 Mbps	3.181 Mbps	1.363 Mbps
	Medium	11.067 Mbps	7.746 Mbps	3.32 Mbps
	High	16.32 Mbps	11.424 Mbps	4.896 Mbps
Premium	Low	16.16 Mbps	11.312 Mbps	4.848 Mbps
	Medium	39.352 Mbps	27.546 Mbps	11.805 Mbps
	High	58.026 Mbps	40.618 Mbps	17.407 Mbps

and

Table 5. Minimum bandwidth requirements for PtCl live video.

User Level	Number of PtCl	Minimum Required Bandwidth
Regular	Low	33.218 Mbps
	Medium	56.497 Mbps
	High	83.7 Mbps
Premium	Low	541.655 Mbps
	Medium	921.24 Mbps
	High	1364.8 Mbps

detail the minimum bandwidth requirements for 6DoF PtCl video, consolidating specifications from several studies [17,23,51,52,53] according to the density of the PtCl. Table 4 outlines the bandwidth needs for 6DoF PtCl VoD using V-PCC technology. VVC encoding is used for PtCl compression, enhanced by LCEVC. The compression mode, either All-Intra (AI) or Random Access (RA), influences both the compression level and video quality of PtCl. AI mode delivers high-quality video, while RA mode requires half the bitrate of AI mode but with reduced quality. Premium users are provided with the AI encoding mode and a 120-degree FoV, whereas regular users receive the RA mode and a 90-degree FoV, which is more bitrate-efficient. Table 5 presents the bandwidth requirements for 6DoF PtCl live video using G-PCC technology. According to [23], there are three different PtCl processing methods based on FoV: Occlusion Visibility (OV), which excludes occluded PtCl; Distance Visibility (DV), which adjusts PtCl density based on viewing distance; and Viewport Visibility (VV), which transmits PtCl only within and around the FoV. Premium users utilize the OV processing method, while regular users employ a mixed strategy of OV, DV, and VV to minimize bandwidth requirements.

Table 6. Minimum bandwidth requirements for MIV VoD.

User Level	Resolution/Frame Rate	Minimum Required Bandwidth	Bandwidth Required for Base Layer	Bandwidth Required for Enhancement Layer
Regular	1080P/30FPS	12.036 Mbps	7.221 Mbps	4.814 Mbps
	2K/30FPS	24.072 Mbps	16.85 Mbps	7.221 Mbps
	4K/30FPS	52.658 Mbps	36.86 Mbps	15.797 Mbps
	8K/30FPS	180.544 Mbps	126.38 Mbps	54.163 Mbps
Premium	1080P/30FPS	16.056 Mbps	11.24 Mbps	4.816 Mbps
	2K/30FPS	32.112 Mbps	22.478 Mbps	14.4 Mbps
	4K/30FPS	70.245 Mbps	49.171 Mbps	21.073 Mbps
	8K/30FPS	240.84 Mbps	168.58 Mbps	72.252 Mbps

and

Table 7. Minimum bandwidth requirements for MIV live video.

User Level	Resolution/Frame Rate	Minimum Required Bandwidth	Bandwidth Required for Base Layer	Bandwidth Required for Enhancement Layer
Regular	1080P/30FPS	36.892 Mbps	31.358 Mbps	5.533 Mbps
	2K/30FPS	46.116 Mbps	39.198 Mbps	6.917 Mbps
	4K/30FPS	73.785 Mbps	62.717 Mbps	11.067 Mbps
Premium	1080P/30FPS	49.2 Mbps	41.82 Mbps	7.38 Mbps
	2K/30FPS	61.512 Mbps	52.285 Mbps	9.22 Mbps
	4K/30FPS	98.419 Mbps	83.656 Mbps	14.762 Mbps

outline the minimum bandwidth requirements for MIV VoD and MIV live video, respectively [13,14]. In contrast to the PtCl format, MIV video is produced based on 2D video, leading to bandwidth requirements categorized by video resolution. MIV VoD employs VVC encoding enhanced with LCEVC. Conversely, MIV live video utilizes AVC encoding enhanced with LCEVC. Users can select between different configuration modes: MIV View mode and MIV Atlas mode [15]. In View mode, specific details in the atlas are preserved after MIV video synthesis, saving approximately 19% bitrate. Atlas mode involves trimming details in the atlas, resulting in a certain loss of detail and a 39% bitrate reduction. Premium users opt for MIV View mode, while regular users opt for MIV Atlas mode.

In this study, three wireless communication technologies across different frequency bands are utilized. THz [54,55] and mmWave [56] communications are employed to provide bandwidth for vehicle passengers’ applications via V2I communication, while Li-Fi technology within the realm of optical wireless communication [57] is used to relay bandwidth for vehicle passengers’ applications via V2V communication.

Table 8. Wireless communication technology: Transmission distance and bandwidth.

Wireless Communication Technology	Transmission Distance	Maximum Bandwidth Achievable
THz	400 m	327 Gbps
mmWave	1.7 km	20 Gbps
Li-Fi	10 m	224 Gbps

details the maximum achievable bandwidth and transmission distances for these wireless communication technologies.

Figure 3 illustrates the variation in the number of vehicles throughout the day. The graph highlights significant peaks during the morning commute from 7 a.m. to 10 a.m. and the evening commute from 5 p.m. to 8 p.m., with peak values observed at 9 a.m. and 7 p.m., respectively. Vehicle flow increases notably during these peak periods. Between 11 a.m. and 4 p.m., outside of the commute peaks, vehicle flow remains relatively stable, consistently above 3700 vehicles. As night approaches, vehicle flow gradually declines, with the lowest traffic occurring during the late night to early morning hours.

Figure 4 illustrates the usage of video applications among vehicle passengers across various time periods, encompassing 2D video, 360-degree video, PtCl video, and MIV video, categorized into live and VoD formats. The graph demonstrates that VoD usage exceeds live usage across all video types, driven by the convenience of on-demand viewing. Furthermore, due to its widespread availability, 2D video shows the highest usage among all formats. Although the usage numbers for 360-degree video, PtCl video, and MIV video are significantly lower than for 2D video, the immersive video market is anticipated to grow significantly in the future, especially for 360-degree video, projected to rival or surpass the viewership of 2D video. In contrast, the adoption of 6DoF video technology is currently in its early stages, resulting in comparatively lower viewership numbers.

Figure 5 depicts the bandwidth requirements across various types of video applications. The graph highlights that 360-degree video demands the highest bandwidth, followed by immersive MIV video. The popularity of 360-degree video, coupled with the need for extensive data transmission to support a panoramic viewing experience, significantly drives up its bandwidth requirements compared to other video formats. In contrast, immersive PtCl and MIV videos, while also bandwidth-intensive, exhibit overall demands similar to that of 2D video due to their lower market penetration. MIV video, which involves synthesizing multiple videos during encoding, consequently incurs slightly higher bandwidth requirements than PtCl video. Moreover, live video applications, which prioritize low-latency requirements, employ encoding techniques that minimize latency but lead to lower compression rates and therefore higher bandwidth demands compared to VoD.

Figure 6 provides a visual representation of the bandwidth allocation situation before the proposed bandwidth allocation approach is applied. As the number of vehicles on the network increases, there is a corresponding rise in the total demand for bandwidth. This surge in demand often leads to network congestion, especially during peak traffic hours. During these congested periods, users experience significant competition for available bandwidth resources. This competition can result in adverse effects such as delays or interruptions for video applications. New passengers may find it difficult to start video sessions altogether, while existing users may encounter buffering issues or frequent pauses while streaming video content.

Figure 7 provides a detailed depiction of the bandwidth allocation strategy after the implementation of the proposed algorithm, focusing on various types of video applications. The graph prominently displays a significant increase in the allocated bandwidth specifically designated for live video applications.

At the core of this enhancement is the “Bandwidth Assignment Coordination” module, which operates within RSUs. This module assumes a critical role in efficiently managing bandwidth reassignment when demand exceeds available resources. Its primary function involves dynamically reallocating bandwidth from non-real-time applications to real-time applications, such as live video streaming, as necessary. This adaptive reallocation ensures that critical applications requiring real-time data transmission, like live video feeds, consistently receive adequate bandwidth even during peak demand periods.

In addition to the above-mentioned “Bandwidth Assignment Coordination” module, the “Vehicle Fleet Bandwidth Coordination” module, leverages advanced 6G technology and Li-Fi V2V communication within vehicular networks. This module improves the total bandwidth utilization of vehicular networks by tapping into CF XL-MIMO wireless access points across different road segments. By redistributing surplus bandwidth from CF XL-MIMO access points at less-congested road segments to vehicles experiencing shortages, it effectively addresses bandwidth deficiencies in congested areas, thereby enhancing overall network performance.

Furthermore, the system incorporates the “Bandwidth Allocation for Non-Real-Time Applications” module, which operates proactively under uncongested network conditions. This module facilitates the pre-downloading of additional video segments for deferred viewing during journeys as vehicles pass through less congested road segments. This approach ensures uninterrupted non-real-time services even during peak periods when bandwidth is primarily allocated to real-time applications, thereby preventing service disruptions or degradation in quality due to bandwidth constraints.

Figure 8 provides a detailed illustration of the dynamic changes in bandwidth demand for all video applications within congested road segments throughout the day. During the timeframe from 7:00 a.m. to 10:00 p.m., it becomes apparent that the cumulative bandwidth requirements of vehicles in these congested areas surpass the capacity that CF XL-MIMO access points can provide. This limitation is clearly depicted by the green flat curve in Figure 8, indicating that many users experience unmet bandwidth needs during peak hours due to the constraints of CF XL-MIMO access points in these segments, resulting in compromised service quality and a diminished user experience.

Conversely, the purple curve in Figure 8 highlights the efficacy of the proposed bandwidth allocation approach in addressing these challenges. By leveraging cooperative vehicle fleets and utilizing V2V communication technology, our approach facilitates the transfer of surplus bandwidth from CF XL-MIMO access points located in less congested road segments to vehicles in high-traffic areas. This strategic redistribution significantly augments available bandwidth beyond the limits of CF XL-MIMO access points in congested segments.

To summarize, Figure 8 underscores how our innovative approach effectively manages bandwidth allocation dynamics, optimizes network performance, and ensures a more robust and reliable experience for vehicle passengers using video applications in varying traffic conditions.

4. Conclusions

Many studies have traditionally focused on resource allocation in vehicular networks, primarily centered on current technologies and often overlooking the imminent advancements expected with 6G technology and emerging multimedia applications slated for integration into in-vehicle entertainment systems. This research addresses the critical area of bandwidth allocation for next-generation vehicular multimedia applications. By integrating cutting-edge wireless communication technologies such as mmWave, THz, and CF XL-MIMO, we aim to deliver efficient and stable bandwidth, ensuring uninterrupted service while vehicles are in motion. Additionally, we leverage Li-Fi technology for V2V communication, enabling flexible utilization of excess bandwidth from CF XL-MIMO access points located in less congested road segments.

In addition to these advancements, we leverage Li-Fi technology for V2V communication, allowing for the flexible utilization of idle bandwidth from adjacent road sections. This strategic use of Li-Fi enhances bandwidth availability dynamically, adapting to the varying demands across different road segments.

In order to meet the diverse demands of different video applications, we utilize a variety of encoding techniques and implement dynamic adjustments to video quality based on real-time network conditions. This strategy is designed to enhance transmission efficiency, ensuring that each video type receives adequate bandwidth and maintains a high-quality viewing experience tailored to the current network conditions.

The effectiveness of our approach is substantiated by simulation results. By implementing advanced mechanisms such as VoD pre-download strategies and techniques for bandwidth reassignment and relay, we ensure seamless video playback even during peak traffic hours. Furthermore, our fleet bandwidth transfer mechanism is essential for reallocating unused bandwidth from road sections with less congestion to those with higher traffic, leading to a significant boost of 32% in bandwidth availability during peak periods. This enhancement effectively meets user demand and significantly enhances overall viewing experiences, mitigating issues such as buffering or delays caused by insufficient bandwidth.

Although we have integrated several innovative strategies aimed at alleviating bandwidth constraints in congested road segments, thereby greatly enhancing passenger video experiences during peak traffic conditions, there are still several limitations and potential issues for further investigation.

Firstly, compared to lower frequency bands, mmWave and THz suffer from higher path losses, limiting transmission distances. Therefore, the introduction of XL-MIMO antennas aims to mitigate these propagation challenges [58]. However, due to the high deployment costs of large-scale antennas, telecommunications providers tend to deploy XL-MIMO antennas in high-traffic hotspot areas to save on operational costs [59]. Additionally, the mobility of vehicles can lead to dynamic network topologies and frequent resource reallocations, making it essential to maximize resource utilization and energy efficiency. Thus, efficient energy management is crucial for ensuring the sustainability of 6G networks. To this end, artificial intelligence (AI) can be employed to achieve adaptive resource management by leveraging historical data and real-time sensor information to predict future traffic loads, preemptively allocate resources to avoid potential network congestion, and optimize the overall user experience [60].

As the pursuit of more efficient and reliable communication technologies continues in V2X communication, issues of security and privacy protection have become increasingly prominent. Given the extensive data exchange between vehicles and infrastructure in V2X communication, including vehicle location, speed, navigation information, and passenger data, the confidentiality, integrity, and availability of these data are crucial. Blockchain has emerged as a popular research focus in recent years in the field of information security, due to its decentralization, transparency, and resistance to data tampering [61]. Combining blockchain with other emerging technologies such as edge computing and AI can enhance real-time data processing and decision-making capabilities in V2X networks. By addressing these challenges, future research can significantly contribute to the development of secure, efficient, and sustainable 6G vehicular networks, thereby advancing the field of intelligent transportation systems and the realization of smart cities.