Hybrid network communication system for network connection cooperative driving

Abstract

The invention belongs to the field of vehicle networking communication, and particularly relates to a hybrid network communication system for network connection cooperative driving, which comprises the following steps: analyzing urban road straightaway and highway straightaway scenes including scene composition and scene traffic flow; deploying RSU and MEC calculation units according to scene analysis; establishing a multi-mode communication and hybrid network topology structure; a hybrid network cooperative lane changing communication system is established according to multimode communication and a hybrid network topology structure, and comprises a vehicle end system, a road side system and a cloud control platform; based on a hybrid network cooperative lane changing communication system, executing a CAV cooperative lane changing driving service; the continuity of cross-network communication is realized, and an efficient, low-delay and high-reliability cooperative driving task is realized.

Description

Technical Field

[0001] The present invention belongs to the field of vehicle networking communications, and specifically relates to a hybrid network communication system for networked collaborative driving. Background Art

[0002] With the widespread deployment of 5G communication technology and the continuous advancement of intelligent transportation systems, connected and automated vehicles (CAVs) are gradually achieving efficient information exchange between vehicles (V2V), vehicles and infrastructure (V2I), and vehicles and networks (V2N). Cooperative control has become a key means for CAVs to improve road safety and operational efficiency.

[0003] Traditional communication architectures often rely on fixed modes, making them prone to unstable communication links and delayed collaborative control when faced with high-speed mobility, communication interruptions, or excessive computing pressure on edge nodes. Furthermore, architectures that rely too heavily on a single communication mechanism struggle to flexibly address the diverse demands for low latency, high reliability, and multi-coverage communications in densely populated urban areas and high-speed scenarios.

[0004] At present, although my country has planned to promote the construction of nationwide cellular vehicle-to-everything (C-V2X) communication infrastructure, due to the incomplete deployment of road side units (RSU) and limited coverage of edge computing (MEC) resources, it is difficult to fully support the implementation of collaborative driving tasks by relying solely on centralized or distributed communications. To this end, a hybrid network communication system that integrates multiple communication mechanisms, has flexible scheduling capabilities, and is task-oriented and environmentally adaptive is proposed, which becomes the key path to achieve efficient and reliable networked collaborative driving. In the centralized communication architecture, RSU and MEC collaborate to achieve vehicle-road collaborative control, traffic flow coordination and centralized scheduling, which is suitable for high-density and complex traffic scenarios; in the distributed communication architecture, vehicles communicate directly through the proximity communication interface (PC5), which is suitable for low-latency, local collaborative control scenarios. Therefore, how to integrate the advantages of centralized and distributed communication architectures to build a hybrid network communication system that can dynamically switch, integrate resources, and be highly reliable to support the needs of connected collaborative driving with cross-network collaboration capabilities, low-latency communication mechanisms, and flexible switching strategies has become an important research direction for current connected collaborative driving systems. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a hybrid network communication system for networked collaborative driving. To achieve the above purpose, the present invention provides the following technical solutions:

[0006] S1. Analyze straight road scenarios on urban highways and expressways, including scene composition and traffic flow.

[0007] S2. Deploy RSU and MEC computing units based on scenario analysis;

[0008] S3. Establish multi-mode communication and hybrid network topology;

[0009] S4. Establish a hybrid network cooperative lane-changing communication system based on multi-mode communication and a hybrid network topology, which includes a vehicle-side system, a roadside system, and a cloud control platform;

[0010] S5. Execute CAV collaborative lane-changing driving services based on a hybrid network collaborative lane-changing communication system.

[0011] Furthermore, step S1 includes:

[0012] S11, urban highway straight road and highway straight road scenes include car, road and cloud, among which,

[0013] Vehicle types are divided into human-driven vehicles (HDV) and connected autonomous vehicles (CAV). CAVs are divided into three categories according to the communication methods supported by the on-board communication unit (OBU): only supporting PC5 direct communication, only supporting cellular wireless interface (Uu Interface, Uu) communication, and dual-mode communication (i.e., supporting both PC5 direct communication and Uu communication). All CAVs are also equipped with a local collaborative control unit for collaborative driving and dynamic communication mode switching. For CAVs that support both PC5 direct communication and Uu communication, their communication modes will be flexibly switched according to vehicle-road collaboration and regional density.

[0014] Road types include urban highway straights and expressway straights, and roadside facilities include basic facilities, monitoring equipment, and auxiliary communication equipment; among them, auxiliary communication equipment includes RSU, MEC servers, and 5G operator base stations.

[0015] The cloud server is the cloud control platform that supports C-V2X services. The cloud control platform is used to store, calculate, and analyze basic vehicle-side and road-side information. The cloud control platform provides various big data application services to the vehicle side through 5G base stations, including high-precision map loading and local information distribution. The cloud control platform also monitors the communication network status, including network load and connection quality.

[0016] S12. For traffic flow in urban straight roads and highway straight roads, the following key concepts and adaptation strategies are defined:

[0017] a) CAV node penetration and communication strategy selection:

[0018] CAV node penetration rate: CAV node penetration rate refers to the ratio of the number of CAVs in a specific area to the total number of vehicles in that specific area. CAV node penetration rate is an important parameter affecting the selection of communication mode and topology adaptive switching.

[0019] Under the hybrid communication architecture, the system dynamically switches regional communication modes based on real-time CAV penetration levels. The system considers regions with CAV penetration levels in the range [0, 0.3) as ultra-low, [0.3, 0.6) as medium-low, and [0.6, 1] as high. Different communication strategies are implemented for different penetration levels:

[0020] In high-penetration areas, a communication mode is adopted that is mainly V2V distributed communication and supplemented by RSU centralized scheduling; in medium- and low-penetration areas, a communication mode is adopted that is mainly centralized communication and supplemented by distributed communication, and collaborative behavior is guided by RSU and MEC; in ultra-low-penetration areas, the focus is on relying on RSU and the pre-control platform to build a multi-hop communication and remote collaboration mechanism to enhance system stability and reliability.

[0021] b) CAV dense / sparse distribution and communication strategy adaptation:

[0022] Sparsely distributed CAVs: In the hybrid communication architecture, the system will strengthen the RSU coverage and multi-hop relay mechanism (V2V and RSU forwarding). For example, when vehicle nodes are sparse, the communication distance between CAVs is too long, resulting in link obstruction. RSUs can be used for relaying to extend the effective communication distance, complete inter-CAV communication, and ensure effective communication between sparse nodes. At the same time, edge MEC centralized control is enabled to supplement the command window period that may be caused by V2V communication interruption.

[0023] CAVs are densely distributed: V2V direct connections are prioritized in combination with local dynamic networking to alleviate RSU link pressure, and a distributed resource management mechanism is adopted to avoid channel congestion. RSUs provide auxiliary scheduling and conflict perception mechanisms, automatically intervening for coordination and guidance when channel congestion and increased interference are detected.

[0024] c) Traffic flow adaptation strategy in urban straight road scenarios:

[0025] Urban roads usually have the characteristics of high traffic density, short communication distance, and variable interaction nodes;

[0026] In the hybrid communication architecture, the system combines the following strategies: distributed V2V communication is used to support high-frequency vehicle interactions and real-time local perception sharing; centralized V2I communication is responsible for supplementing and verifying services such as complex lane changes, traffic light perception, and path instructions; RSU and MEC are deployed at high-interaction frequency locations such as intersections and road midpoints to support collaborative perception and control.

[0027] d) Traffic flow adaptation strategy in highway straight lane scenarios:

[0028] Highway traffic is characterized by high speeds, large relative distances between vehicles, and rapid topological changes. In the hybrid architecture, the traffic flow density segmentation strategy is as follows:

[0029] Near highway entrances / exits (high-density areas): A communication mode based on RSU centralized management and supplemented by V2V is adopted. MEC perceives and guides potential conflicts and merging behaviors between nodes; and enables short-term centralized coordination strategies (such as ramp merging management and collaborative lane change guidance).

[0030] Sparsely populated road sections far from highway entrances and exits: Prioritize the use of V2V-based communication with RSU remote relay as a supplement; MEC is only activated to issue control strategies in critical events (such as emergency lane changes and lane occupancy); at the same time, based on the self-organizing network mechanism of on-board nodes (such as cluster head coordination), low-interference, highly reliable collaborative behavior is achieved.

[0031] Furthermore, in step S2, RSU and MEC computing units are deployed based on the analysis results of the urban straight road and highway straight road scenarios.

[0032] Under the hybrid communication architecture, the deployment of roadside equipment will consider a combination of centralized roadside computing and distributed vehicle communications for different road scenarios and vehicle distribution conditions. The deployment requirements will improve the efficiency and reliability of the Internet of Vehicles system through flexible network switching mechanisms, distributed data processing, and collaborative optimization of edge computing.

[0033] Regarding basic requirements, on straight sections of highways, the high-speed mobility of vehicles requires optimized RSU deployment spacing to ensure stable connectivity for high-speed vehicles and avoid communication blind spots. RSU spacing should consider communication performance and adaptability to high-mobility environments. A spacing of 500 to 1000 meters is generally recommended, with a MEC computing unit deployed near each RSU. On straight sections of urban highways, the focus is on ensuring V2I communication quality. When setting RSU spacing, a comprehensive consideration of equipment cost and performance is required. Considering high-density urban environments, a spacing of 200 to 500 meters is recommended, with a MEC computing unit deployed near each RSU to ensure uninterrupted communication between vehicles and roadside infrastructure on urban roads.

[0034] Requirements for RSU and MEC deployment under sparse distribution of vehicle nodes:

[0035] Deployment spacing: To ensure communication quality on roads with sparsely distributed vehicle nodes, the RSU deployment spacing can be increased, reducing the overall deployment quantity. The specific spacing for straight highway sections and urban straight road sections can be set to 1000 to 1500 meters and 400 to 800 meters, respectively. By enhancing the communication capabilities of the RSUs, reliable communication coverage over a large area is ensured. In this scenario, the RSUs and MEC computing units can share computing resources, meaning that a single MEC computing unit manages multiple RSUs, reducing the number of devices and improving resource utilization efficiency. The MEC computing unit is responsible for managing computing tasks over a large area and providing real-time data analysis and collaborative driving guidance to vehicles.

[0036] Location selection: RSUs and MEC computing units should be deployed in unobstructed locations to ensure signal stability and reliability. Deployment locations should be rationally planned based on the road's terrain and vehicle flow to ensure that all vehicles within the coverage area have access to good communication support. On roads with sparsely distributed vehicle nodes, priority should be given to covering key points with relatively concentrated traffic flow, such as service areas and entrance and exit ramps. For long straight sections of highways, RSUs and MEC computing units should be deployed in open areas on both sides of the road to avoid signal obstruction caused by roadside buildings or other obstacles.

[0037] Requirements for RSU and MEC deployment under densely distributed vehicle nodes:

[0038] Deployment spacing: In sections with dense vehicle nodes, the deployment spacing of RSUs needs to be reduced to ensure the smooth flow of V2I link channels in order to cope with the network load and interference caused by high-density traffic flow. To this end, high-density RSUs are deployed in areas with high vehicle density; in scenarios with dense vehicles, multi-point distributed MEC nodes are deployed close to the RSUs, that is, each RSU can be equipped with multiple MECs. Specifically, the RSU spacing for straight sections of highways and straight sections of urban highways should be set to 400 meters to 800 meters and 200 meters to 400 meters, respectively, to ensure network stability and real-time performance. In this environment, the MEC computing unit will be responsible for managing multiple RSUs. The number of RSUs managed by each MEC computing unit is usually 2 to 3, and resources are dynamically adjusted and allocated according to the traffic density and communication needs of the section.

[0039] Location selection: RSUs and MEC computing units should be installed in unobstructed locations to ensure the widest possible coverage. Especially on urban roads, deployment should be done in areas with frequent vehicle traffic, such as intersections and through sections of intersections, to ensure signal transmission quality.

[0040] Signal enhancement: In areas with dense vehicle nodes, the RSU's signal transmission power may need to be increased. Signal enhancement equipment, such as directional antennas and power amplifiers, can be installed to enhance signal coverage and transmission stability, ensuring good communication between vehicles and between vehicles and roadside facilities.

[0041] Furthermore, in step S3, the communication nodes in the multi-mode communication and hybrid network topology include: cloud control platform, full-coverage 5G base stations, RSU, MEC, and vehicles; vehicles include HDV and CAV, among which the cloud control platform provides global perception and information fusion, maintenance and distribution of high-precision maps and traffic information, task management and resource scheduling, etc.

[0042] Full coverage of 5G base stations provides wide-area communication support and cloud access capabilities, suitable for scenarios such as remote scheduling and cross-regional information synchronization;

[0043] RSUs are deployed on key roads to support short-range communication, sensor fusion, edge computing, and V2I scheduling.

[0044] CAVs are divided into three types according to the communication mode, including: CAVs that only support PC5 direct communication, CAVs that only support Uu communication, and CAVs that support both PC5 direct communication and Uu communication; CAVs that only support PC5 direct communication self-organize to form "clusters" among local vehicles through V2V communication, and accept centralized scheduling within the RSU coverage area; CAVs that only support Uu communication give priority to accessing the network through 5G base stations, and are suitable for urban remote services, cloud navigation, etc.; CAVs that support both PC5 and Uu communication have dual-mode capabilities. The system dynamically switches communication modes according to network load, latency requirements and geographic location, and by default gives priority to collaborative communication with RSU through PC5 direct connection.

[0045] The multi-mode communication and hybrid network topology is a fusion structure composed of star, tree, and mesh structures, including: A. Connecting each RSU and each 5G base station as the center to obtain different star structures;

[0046] B. With the cloud control platform as the root node and the RSU and MEC computing units as relay nodes, a hierarchical scheduling topology is constructed to obtain a tree structure.

[0047] C. Vehicles with PC5 direct communication capabilities build a horizontal mesh structure through V2V.

[0048] Furthermore, the cloud control platform is used to collect and integrate data uploaded by the vehicle-side system and the roadside system, realize global environment modeling and traffic situation awareness, and distribute high-precision map and other information;

[0049] The roadside system includes 5G base stations, RSUs, and MEC computing units. These are used to cache high-precision maps issued by the cloud control platform and forward feedback information to the vehicle-side system. The RSUs sense and acquire local environmental information and upload it to the cloud control platform or MEC computing unit. The MEC computing unit is equipped with a collaborative control unit for local lane change decision-making, trajectory optimization, and emergency intervention control.

[0050] The vehicle-side system includes HDV and CAV. HDV only exists as a perception object and participates in the lane change trajectory optimization process; CAV is used to perceive vehicle information and, combined with feedback information from the roadside system, execute lane change trajectory planning, control command response and local exception handling.

[0051] Furthermore, in step S4, the vehicle-side system is used to implement autonomous networking and intelligent switching of communication paths between vehicles. The CAV is equipped with a local collaborative control unit for identifying vehicle driving intentions and executing trajectory planning. The vehicle-side system adopts a vehicle-side multi-mode communication method, including:

[0052] PC5 priority mode: Vehicle nodes within the same coverage area communicate directly via PC5;

[0053] Uu priority mode: Vehicle nodes that support both PC5 direct communication and Uu communication give priority to using the Uu interface to communicate with RSU and 5G base stations;

[0054] Uu communication supplementary mode: cross-regional vehicle nodes communicate through 5G base station relays;

[0055] Cross-network collaboration mode: Vehicle nodes that only support PC5 direct communication interact with vehicle nodes that only support Uu communication through RSU and 5G base stations; vehicle nodes that only support PC5 direct communication interact with vehicle nodes that support both PC5 direct communication and Uu communication through RSU; vehicle nodes that only support Uu communication interact with vehicle nodes that support both PC5 direct communication and Uu communication through 5G base stations; 5G base stations communicate and transmit with the cloud control platform through optical fiber connections.

[0056] Furthermore, in step S5, based on the constructed hybrid network cooperative lane change communication system, a CAV cooperative lane change driving service is executed:

[0057] A1. After the target CAV triggers a lane change intention, it first determines whether it is executable within its own OBU. If the judgment result is executable, the local collaborative control unit generates a lane change request based on the lane change intention, broadcasts the lane change request information to the neighboring CAVs, and simultaneously sends the lane change request information to the MEC computing unit through the RSU.

[0058] A2. The collaborative control unit integrated into the MEC computing unit performs intent recognition based on cached data and generates collaborative lane change trajectory instructions;

[0059] A3. Determine whether the target CAV is located in an RSU low coverage area. If so, execute step A4; if not, execute A5.

[0060] A4. The MEC computing unit sends the coordinated lane change trajectory command to the target CAV. The local coordinated control unit of the target CAV selects a coordinated vehicle based on the coordinated lane change trajectory command and sends a coordinated lane change request to the coordinated vehicle via V2V communication. The coordinated vehicle returns a coordinated lane change response via V2V communication. The target CAV then sends a road control command to the coordinated vehicle, completing the coordinated lane change.

[0061] A5. The collaborative control unit integrated in the MEC computing unit selects a collaborative vehicle and sends a collaborative lane change request to the collaborative vehicle through the RSU. The collaborative vehicle uploads a collaborative lane change response to the RSU. The MEC computing unit then sends a road control command to the collaborative vehicle, enabling the roadside to guide and control the collaborative vehicle and complete the collaborative lane change.

[0062] A6. The target CAV reports the execution result to the MEC computing unit, which determines whether to trigger rescheduling or downgrade processing based on the execution result.

[0063] In addition, the RSU receives and fuses the roadside perception data from the integrated radar and camera equipment and the vehicle-side perception data from the vehicle in real time, and then sends the fused data to the MEC computing unit for caching; the RSU regularly sends periodic services to the vehicle; when a CAV vehicle within the RSU range triggers a lane change condition, the periodic service information is not interrupted with the lane change trigger. While the collaborative lane change driving service is being executed, periodic service communications are still carried out between the RSU and the vehicle.

[0064] The beneficial effects of the present invention are:

[0065] The present invention realizes adaptive communication strategies in different scenarios by dynamically adjusting the communication mode and flexible link selection mechanism. The system optimizes the load, stability and reliability of the communication link according to scenarios such as urban straight roads and highways and the distribution of CAVs, thereby ensuring the efficient execution of task collaboration. It adopts multi-mode communication technology, supports PC5 direct connection, Uu cellular communication and dual-mode communication, ensures seamless connection between vehicles, roadsides and the cloud, and adapts to different traffic densities and complex environments. At the same time, the system improves perception fusion, edge computing and global scheduling capabilities through multi-level collaboration of RSU, MEC and cloud platforms, realizes rapid response to traffic events, task allocation and execution, effectively reduces system delays, and enhances the stability and intelligence level of the overall system. The flexible deployment of roadside equipment improves communication coverage and data processing efficiency, ensuring the reliability and adaptability of vehicle-road collaborative control.

[0066] Other advantages, objects, and features of the present invention will be described in part in the following description and, in part, will be apparent to those skilled in the art upon examination of the following description or may be learned from practice of the present invention. The objects and other advantages of the present invention may be realized and obtained through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention will be described in detail below with reference to the accompanying drawings, in which:

[0068] Figure 1 A schematic diagram of a hybrid communication architecture for coordinated urban straight-road driving according to the present invention;

[0069] Figure 2 Schematic diagram of the RSU deployment solution for the straight road scenario of the present invention;

[0070] Figure 3 A schematic diagram of the topological structure of vehicle nodes with different communication modes under a hybrid communication architecture of the present invention;

[0071] Figure 4 This is a schematic diagram of the communication data flow for cooperative lane-changing under urban straight roadside guidance;

[0072] Figure 5 A schematic diagram of a cooperative lane change scenario on a straight road in an urban area according to the present invention;

[0073] Figure 6 The figure is a schematic diagram of the overall communication process of CAV under the hybrid communication architecture on urban straight roads. DETAILED DESCRIPTION

[0074] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0075] See also Figures 1 to 6 This paper proposes a hybrid network communication system for connected collaborative driving, which includes a hybrid communication architecture for collaborative lane-changing driving in straight-line scenarios. This hybrid communication architecture not only considers the deployment of roadside equipment in actual traffic scenarios, but also addresses the communication processes of different on-board communication interfaces, such as the Uu interface and the PC5 interface, while integrating edge computing and cloud computing capabilities. The hybrid communication architecture can flexibly switch between centralized and distributed communication modes according to the requirements of different business scenarios. This optimizes the existing centralized communication architecture, especially in terms of the flexibility and real-time performance of scenario and business processing.

[0076] Specific plans include:

[0077] S1. Analyze the straight road scenes of urban roads and highways, including scene composition and scene traffic flow.

[0078] Specifically, in terms of traffic scene composition, the scene involved in the present invention includes three components: car, road, and cloud. Figure 1 The following is a detailed description of the elements in the scene.

[0079] a) Vehicle types include human-driven vehicles (HDVs) and connected and autonomous vehicles (CAVs).

[0080] b) The roads are Class III or higher, and the road sections are straight sections, including straight sections on expressways and urban highways. Roadside facilities include basic infrastructure, monitoring equipment, and auxiliary communication equipment. Basic infrastructure includes traffic signs, signal lights, guardrails, lighting equipment, etc. Monitoring equipment is used to collect local road section information, including cameras, millimeter-wave radars, and lidars, which together form a radar-camera integrated device. Auxiliary communication equipment is used to support vehicle-to-everything (V2X) communication and computation offload tasks, including roadside units (RSUs) that support vehicle-to-road communication; MEC computing units that integrate, analyze, and control local vehicle-to-road data; and 5G operator base stations with full communication coverage.

[0081] c) Cloud servers are mainly cloud control platforms for domestic operators. They play the role of storage and computing tasks, mainly providing large-scale data storage, analysis and remote computing, supporting the collaborative operation of edge computing nodes, but not directly processing local low-latency tasks.

[0082] Specifically, the scene traffic flow analysis of the present invention includes the following contents:

[0083] a) CAV node penetration analysis:

[0084] CAV node penetration refers to the ratio of CAVs to the total number of vehicles in a specific area. When CAV node penetration is low, HDV behavior can lead to traffic congestion. MEC computing units and RSUs can provide real-time, localized decision-making and data processing support to help smooth traffic. When CAV node penetration is high, CAVs facilitate traffic flow, enhance vehicle-to-vehicle connectivity, and improve traffic efficiency.

[0085] b) Analysis of the impact of sparse / dense CAV access on network communications:

[0086] In scenarios where CAVs are sparsely distributed, it is difficult to establish a stable link for direct communication between vehicles, resulting in reduced collaborative control efficiency. To ensure communication coverage and service continuity, the system needs to build multi-hop relay links and edge computing support. For example, V2V communication can relay communication through RSUs that cover a wider communication area, providing broader network access capabilities and reducing communication blind spots; the MEC computing unit locally performs collaborative lane change-related calculations and decisions, avoiding uploading large amounts of raw perception data to the cloud, thereby reducing latency.

[0087] In scenarios with densely distributed CAVs, the overall system communication capacity demand increases, making it prone to communication resource conflicts, channel congestion, and increased transmission delays. To address these challenges, MEC computing units perform local perception fusion and lane change decisions at the edge, reducing the communication load on the core network (using distributed communication to transfer computing tasks to different computing nodes). This enables regional distributed processing and scheduling of tasks, improving the system's scalability under high-density access conditions.

[0088] c) In urban straight road scenarios, the traffic environment is complex, intersections are dense, and traffic density fluctuates greatly, especially during peak hours in the morning and evening. To address this type of dynamically changing traffic characteristics, the hybrid network communication architecture can adjust the allocation strategy of communication and computing resources based on real-time traffic density, including:

[0089] High-traffic areas: During peak traffic hours or in areas with dense traffic, the MEC computing unit and the RSU collaborate to handle a large number of real-time communication tasks. The MEC computing unit is responsible for local lane change decisions and data fusion, quickly responding to multi-vehicle collaboration requests in dense areas. Vehicles communicate with surrounding vehicles and RSUs via PC5 links for low-latency communication, forming a combined horizontal and vertical control path.

[0090] Areas with sparse traffic: During off-peak hours or when traffic is relatively sparse on specific roads, the system can reduce the use of communication resources and switch to a lightweight collaborative mode.

[0091] d) Analysis of traffic flow changes in highway straight lanes:

[0092] Highway straight-line scenarios feature high vehicle speeds, simple topology, and high communication latency requirements. However, traffic volume varies significantly across different areas. Therefore, the hybrid architecture requires tailored communication and control strategies.

[0093] Areas with dense traffic (such as entrances and exits / toll booths): Traffic is concentrated near highway entrances and exits, service areas, or toll booths, making short-term congestion more likely. The system can use locally dense RSU and MEC deployments to build high-bandwidth, low-latency regional microservice communication units. The MEC computing unit handles decision-making tasks such as coordinated lane changes and acceleration / deceleration guidance nearby, and quickly exchanges commands with vehicle OBUs through the RSU.

[0094] Areas with sparse traffic (such as highways far from cities): Highways far from entrances and exits typically have low traffic volumes, sparsely populated vehicles, and high speeds. This reduces the density of RSU deployment, provides wide-area coverage through 5G base stations, and performs periodic collaborative computing with MEC computing units deployed at key locations.

[0095] S2. Deploy RSU and MEC computing units based on scenario analysis.

[0096] The effective communication radius of roadside RSU is generally between 400-600m. To ensure the high quality of V2I communication, in the present invention, the deployment of RSU and MEC computing units is divided into three situations: basic requirements, RSU and MEC deployment requirements for sparse distribution of vehicle nodes, and RSU and MEC deployment requirements for dense distribution of vehicle nodes.

[0097] In one embodiment of the present invention, the basic requirements for straight sections of highways, the RSU and MEC deployment requirements for sparsely distributed vehicle nodes, and the RSU and MEC deployment requirements for densely distributed vehicle nodes are considered in detail, including:

[0098] In the basic requirements, the straight road sections of the highway are usually free of interference from tall buildings or vegetation, and the RSU spacing can be set to 500 meters to 1000 meters to ensure good signal coverage, such as Figure 2 To ensure communication quality for two-way traffic and reduce line-of-sight obstructions, the RSU is typically deployed at the center of a gantry or on the cross arm of a roadside pole, with a vertical height of ≥5 meters. Furthermore, an MEC computing unit is deployed near each RSU.

[0099] In the case of sparsely distributed vehicle nodes, the deployment distance between RSUs can be appropriately increased (1000-1500 meters) compared to the general situation to reduce equipment deployment costs. At the same time, the centralized computing resources of the MEC computing unit can improve overall efficiency. The MEC computing unit is responsible for managing the computing tasks of multiple RSUs to ensure the effectiveness of remote or edge computing.

[0100] Regarding RSU and MEC deployment requirements for densely distributed vehicle nodes, in densely populated areas such as highway ramps and toll booths, RSU spacing should be reduced to 400-800 meters to ensure communication quality under high-density traffic. MEC computing units provide centralized computing within the region, supporting computing task sharing among multiple RSUs, optimizing computing resource utilization, and ensuring low latency and packet loss. For the latter two deployment requirements, RSU and MEC computing units should be placed in prominent locations on both sides of the road, such as on roadside poles, to reduce signal interference caused by terrain or vegetation. MEC computing units can be deployed in nodes with high traffic volume to support the computing resources of the corresponding RSUs. Furthermore, in urban areas or areas with complex terrain, the RSU's transmit power can be increased as needed to overcome signal attenuation. MEC can also dynamically adjust the allocation of computing resources to ensure timely response to communication needs in high-density nodes.

[0101] In this hybrid deployment, the MEC computing unit not only shares the computing load but also optimizes resource allocation through intelligent scheduling:

[0102] Dynamic computing resource allocation: Based on factors such as traffic flow and communication load, MEC can intelligently allocate computing tasks to different RSUs and vehicle nodes to ensure low latency and efficient computing response.

[0103] Integration of heterogeneous computing resources: MEC can combine cloud computing and edge computing to distribute tasks, offloading heavy-load computing to the cloud while handling low-latency tasks on edge computing devices. This not only improves computing efficiency but also reduces network latency. S3. Establish multi-mode communication and a hybrid network topology.

[0104] The deployment of highway straight roads and urban straight roads is similar, but there are still some differences. Urban straight roads are more easily blocked by obstacles than highway straight roads, so the deployment spacing of RSUs will be smaller.

[0105] S3. Establish multi-mode communication and hybrid network topology.

[0106] Specifically, if Figure 3 As shown in the figure, the multimode communication and hybrid network topology combines PC5 direct communication, Uu cellular communication, and fiber-optic link communication to build a multi-layered network architecture that supports cloud-edge-end collaboration. It features high reliability, low latency, and flexible scalability. The communication nodes in the multimode communication and hybrid network topology include: cloud control platform, full-coverage 5G base stations, RSU, MEC, and vehicles; vehicles include HDVs and CAVs.

[0107] The OBU plays a central role in the V2X network, and its communication interfaces are diverse to meet diverse communication needs. Common OBU interfaces currently available on the market include the PC5 interface and the Uu interface. The present invention is applicable to CAVs that include both the Uu and / or PC5 communication interfaces. The PC5 interface is a direct communication interface based on LTE Vehicle-to-Everything (LTE-V2X) or 5G Vehicle-to-Everything (5G-V2X) technology. It is used for direct communication within the V2X network and is independent of infrastructure such as base stations. Its communication features low latency and high reliability, enabling the transmission of critical safety and traffic efficiency information in a short period of time. The Uu interface is the communication interface between the OBU and cellular network base stations, leveraging the extensive coverage of the cellular network to enable long-distance communication. With the development of 5G technology, the Uu interface can provide high-bandwidth, low-latency communication services, supporting the transmission of large amounts of data. It is used for communication between vehicles and cloud servers, traffic management centers, and the like, uploading vehicle status and location information while simultaneously receiving traffic conditions, navigation information, remote control commands, and the like from the cloud. The present invention divides CAV into three types according to the interface type contained in the OBU, including: CAV supporting only PC5 direct communication, CAV supporting only Uu communication, and CAV supporting both PC5 direct communication and Uu communication.

[0108] Multi-mode communication and hybrid network topology is a fusion structure composed of star, tree, and mesh structures, including:

[0109] Star structure: With each RSU and each 5G base station as the center, multiple vehicle terminals in the area are connected through PC5 direct communication or Uu communication to obtain different star structures; supporting V2I information interaction such as vehicle status reporting, lane change requests, trajectory reception, and perception sharing.

[0110] Tree structure: With the cloud control platform as the root node, the RSU and MEC computing units as relay nodes, and the vehicle-side as the execution node, a tree-shaped communication structure is formed for longitudinal control and information distribution. This structure has hierarchical scheduling capabilities, enabling the unified distribution of cloud maps, traffic rules, and lane change tasks. The MEC performs local optimization calculations, and the RSU completes command forwarding and perception fusion, building a three-level collaborative control system of cloud, edge, and end.

[0111] Mesh structure: With vehicles capable of PC5 direct communication at the core, point-to-point links are established through V2V, creating a horizontal mesh structure. This system supports autonomous networking, communication, and collaboration, including lane change intention confirmation and trajectory prediction, even in scenarios without RSU or 5G base station coverage.

[0112] S4. A hybrid network cooperative lane-changing communication system is established based on multi-mode communication and a hybrid network topology, which includes a vehicle-side system, a roadside system, and a cloud control platform.

[0113] Specifically, the cloud control platform serves as the system's global control center, centrally collecting and integrating data uploaded by vehicle-side and roadside systems to enable global environmental modeling and traffic situation awareness. The cloud control platform is interconnected with each RSU and 5G base station via fiber optic links, ensuring high bandwidth and stable communication.

[0114] Specifically, the cloud control platform includes:

[0115] The global perception module is used to integrate multi-source information from various RSUs, vehicle-side and external traffic perception platforms; the load balancing and switching module is used to realize dynamic distribution of computing load, service migration and network link switching management between cloud-edge and edge-edge.

[0116] The roadside system receives high-precision maps issued by the cloud control platform, caches them and distributes them to the vehicle-side system; the RSU is deployed at key locations on the road, has high-frequency collaboration capabilities with the MEC computing unit, and is responsible for data uploading, command issuance and information relay. The RSU obtains local environmental information through multi-mode sensors (cameras, millimeter-wave radars, lidars, etc.), and uploads the information to the cloud control platform or provides it to the MEC computing unit after fusion; the MEC computing unit is deployed with a collaborative control unit for local lane change decision calculations, trajectory optimization and emergency intervention control, significantly reducing latency and cloud load; the 5G base station is responsible for Uu link maintenance and interaction with the core network.

[0117] The vehicle-side system performs lane change trajectory planning, control command response and local exception handling based on environmental perception and communication feedback information.

[0118] Specifically, the vehicle-side system includes the following:

[0119] S41. Vehicle-side System Composition: The vehicle-side system consists of CAVs and HDVs with varying communication capabilities. Each CAV is equipped with an onboard communication unit and a local collaborative control unit (LCU), enabling node information perception, trajectory calculation, mission execution, and control command response. Specifically, the HDV, as a non-cooperative node, exists solely as a sensing object.

[0120] S42. Multi-mode communication path selection mechanism. To ensure link stability and low-latency transmission for collaborative tasks in different scenarios, the vehicle-side system supports the following communication path mechanisms:

[0121] a) Within the coverage area of the RSU, vehicles that support PC5 direct communication will have priority in communicating with the RSU directly via PC5;

[0122] b) When a vehicle enters an RSU weak coverage or blind area, vehicles that support Uu communication capabilities automatically switch to the Uu link and communicate with the MEC computing unit through the 5G base station;

[0123] c) Dual-mode terminal vehicles dynamically switch between PC5 and Uu or use them together based on link quality indicators (such as signal-to-noise ratio, delay, bandwidth, etc.);

[0124] d) In high-speed driving or sparsely populated vehicle scenarios, distributed PC5 communication is preferred to improve low-latency characteristics;

[0125] e) In densely populated urban environments or areas with complex obstructions, centralized Uu communication is preferred to ensure link reliability.

[0126] Link adaptation is jointly decided by the vehicle-side communication unit and the LCU, and adaptive switching is performed based on the link status, task type, environmental conditions, etc. to ensure uninterrupted communication and timely delivery of control commands.

[0127] S43. Collaborative task role division and switching mechanism.

[0128] In collaborative driving tasks, CAVs can dynamically assume the roles of task initiation node, task relay node, and task collaboration node, among which:

[0129] Task initiating node: proactively proposes a lane change coordination request;

[0130] Task relay node: forwards task information in the PC5 link;

[0131] Task collaboration node: responds to and executes lane-changing collaborative decisions.

[0132] The system flexibly constructs point-to-point direct connections or RSU-based forwarding paths based on the physical distance between vehicles (whether within the V2V range), communication link status (such as whether it is within the PC5 direct connection range), link quality (current communication delay, packet loss, bandwidth, etc.), task urgency (such as lane change conflict risk, path obstacles), and role idle status (whether the node can take on new tasks), to achieve reliable transmission of task information and accurate delivery of control instructions.

[0133] S44, collaborative control function is realized.

[0134] The LCU in each CAV has the following core functions:

[0135] State recognition module: collects vehicle status information such as speed, direction, and position; intention recognition module: determines whether the driver or the autonomous driving system has triggered a lane change request; path planning module: generates a lane change trajectory based on the vehicle status, other vehicle behavior, and roadside suggestions; control response module: accepts remote collaborative trajectories, integrates local planned paths, and controls the vehicle to execute lane changes.

[0136] During the collaboration process, the LCU periodically receives the status (such as position, speed, intention, etc.) of surrounding vehicles and roadside nodes through the V2V or V2I link, realizes multi-source information fusion, forms a complete environmental model, and completes lane change trajectory planning and control execution locally. Combined with multi-mode communication capabilities, the system supports the following two working modes:

[0137] Local priority control mode: When the edge node is capable or the PC5 link is good, the vehicle side autonomously plans and executes. Guidance control mode: In highly complex scenarios, it receives trajectory or command suggestions issued by MEC.

[0138] Specifically, the system of the present invention adopts a communication role mapping mechanism: combining the task scenario and topological location, automatically assigning vehicle task roles (such as main collaborator, relay node, response node), and constructing the optimal path.

[0139] S5. Based on the hybrid network cooperative lane-changing communication system, perform CAV cooperative lane-changing driving business.

[0140] like Figure 4 As shown, based on the S3 multi-mode communication and hybrid topology analysis and the S4 hybrid network cooperative lane-changing communication system analysis, the communication data and specific flow of the straight-line cooperative lane-changing service under the vehicle-road-network hybrid communication are introduced in detail.

[0141] Current V2X communications require transmission of essential safety information, including precise information such as vehicle speed, acceleration, and direction. This information is typically transmitted using the SAE-J2735 message standard. This standardized information allows vehicles and infrastructure to accurately obtain information about the surrounding traffic environment, enabling efficient interaction between V2X devices. Table 1 shows the link message types used in cooperative lane change services.

[0142] Table 1 Cooperative lane change service link message types

[0143]

[0144] Based on the RSU deployment solution given by S2, which involves the decision-making mechanism of on-board local collaboration, MEC edge computing collaboration, and control mode scheduler, there are multiple CAV vehicles within the communication range of the RSU. The hybrid cooperative lane change process steps are as follows:

[0145] A1. When a CAV needs to enter a target lane due to traffic congestion, slow traffic, or due to a need to enter a target lane, it generates a lane change intention (such as a turn signal or navigation path change) through its local environmental perception system (camera, millimeter-wave radar, etc.). The CAV first determines whether the intention is executable within its own OBU. If the determination is executable, the local collaborative control unit (LCU) generates a lane change request message (VIR) based on the lane change intention, broadcasts the VIR to neighboring CAVs, and simultaneously sends the VIR to the MEC computing unit via the RSU.

[0146] Specifically, the CAV that initiates the lane change request information VIR is regarded as the target CAV.

[0147] If the target CAV supports PC5 direct communication, the target CAV broadcasts the lane change request information VIR to the neighboring CAV through PC5, and communicates with the RSU through PC5, and sends the lane change request information VIR to the MEC computing unit via the RSU; if the target CAV only supports Uu communication, the target CAV broadcasts the lane change request information VIR to the neighboring CAV through the 5G base station relay, and communicates with the RSU through the 5G base station relay, and sends the lane change request information VIR to the MEC computing unit via the RSU.

[0148] At the same time, the RSU can simultaneously upload VIR information to the cloud control platform for global monitoring and strategy optimization of lane-changing behavior. After analyzing and aggregating multiple VIR information, the cloud control platform can periodically or event-drivenly issue lane-changing control recommendations, strategy parameters, or risk warning information based on traffic flow modeling and strategy evaluation results, thereby collaboratively optimizing regional lane-changing behavior and traffic order.

[0149] A2. The collaborative control unit integrated into the MEC computing unit performs intent recognition based on cached data and generates collaborative lane change trajectory instructions;

[0150] Specifically, the cached data of the MEC computing unit includes high-precision map information from the cloud control platform and fused perception data SSM from the RSU.

[0151] A3. Determine whether the target CAV is located in an RSU low coverage area. If so, execute step A4; if not, execute A5.

[0152] A4. The MEC computing unit sends the coordinated lane change trajectory command to the target CAV. The local coordinated control unit of the target CAV selects a coordinated vehicle based on the coordinated lane change trajectory command and sends a coordinated lane change request to the coordinated vehicle via V2V communication. The coordinated vehicle returns a coordinated lane change response via V2V communication. The target CAV then sends a road control command to the coordinated vehicle, completing the coordinated lane change.

[0153] A5. The collaborative control unit integrated in the MEC computing unit selects a collaborative vehicle and sends a collaborative lane change request to the collaborative vehicle through the RSU. The collaborative vehicle uploads a collaborative lane change response to the RSU. The MEC computing unit then sends a road control command to the collaborative vehicle, enabling the roadside to guide and control the collaborative vehicle and complete the collaborative lane change.

[0154] A6. The target CAV reports the execution results (trajectory deviation, control delay, and final lane change result) to the MEC computing unit and cloud control platform through the BSM / SSM. The MEC computing unit determines whether to trigger rescheduling or downgrade processing based on the execution results. When there is an abnormality in the execution result (such as vehicle refusal / non-response), rescheduling or downgrade processing may be triggered.

[0155] Specifically, when the target CAV cooperates with the cooperative vehicle to change lanes, it continuously keeps information synchronized with the roadside and adjacent vehicles through the V2X communication link. If an unexpected accident occurs (such as encountering an obstacle ahead), the MEC computing unit can adjust the trajectory in real time.

[0156] Specifically, when the CAV is driving normally in a straight-line scenario and does not trigger the intention to change lanes: the RSU receives the roadside perception data (vehicles, obstacles, etc.) from the integrated radar and camera device and the vehicle-side perception data BSM / SSM from the vehicle in real time and fuses them, and then sends the fused data to the MEC computing unit for caching; the RSU regularly sends periodic services to the vehicle, including RSM, SSM, MAP, SPAT, and RSI; when a CAV vehicle within the RSU range triggers a lane change condition, the periodic service information is not interrupted with the lane change trigger. While the collaborative lane change driving service is being executed, periodic service communications are still carried out between the RSU and the vehicle.

[0157] Specifically, the collaborative control algorithm for roadside-guided cooperative lane-changing tasks is deployed within the MEC computing unit or the V2X service platform of the cloud control platform. The MEC uses vehicle information within range acquired by the roadside unit's sensing devices and estimates the vehicle's driving intention through a consciousness recognition algorithm. Lane change instructions from CAVs within the RSU coverage area and lane change requests from cooperative parties are both provided within the MEC. This hybrid architecture dynamically adjusts the perception computing division of labor and the control lead based on factors such as the current network status, vehicle density, and communication load, enhancing system flexibility and adaptability. This is particularly suitable for high-density urban roads and cross-domain traffic scenarios.

[0158] like Figure 5 As shown in the figure, on a 320-meter urban three-lane straight road with mixed HDVs and CAVs, CAV_7 intends to change lanes right. After initially determining that it is feasible, it broadcasts its intention. The RSU, using a roadside camera, detects HDV_11's intention to change left to Lane 2. The MEC instructs CAV_6 to slow down, creating a gap for the lane change, and issues a stop lane change command to CAV_7. The RSU periodically collects road condition information. When HDV_11 completes the lane change, the MEC issues a lane change command, and CAV_7 executes the lane change based on the received MEC information and its surrounding information. The entire process is jointly controlled by the RSU / MEC and CAV, embodying the advantages of the hybrid architecture of "distributed execution + centralized coordination."

[0159] Specifically, the cooperative lane-changing network requirements under the hybrid communication architecture are as follows:

[0160] To support the aforementioned business processes, hybrid cooperative lane changing places the following requirements on the communication system to be more flexible and robust:

[0161] a) Support dynamic switching and integrated transmission of PC5 and Uu links, prioritize V2I communication in areas with good RSU coverage, and prioritize vehicle-side direct V2V communication for collaborative control in scenarios with signal attenuation or high communication density;

[0162] b) CAVs must have edge collaboration capabilities based on local computing, such as autonomous intent recognition and control in scenarios where the RSU signal is weak or the MEC is offline.

[0163] c) End-to-end communication must meet the low latency requirements of multi-source information synchronization scheduling. The PC5 link latency is less than 50ms, and the 5G network ensures low latency for cloud-to-vehicle interaction over the Uu link (uplink ≥ 20Mbps, downlink ≥ 200Mbps).

[0164] d) The MEC scheduling mechanism needs to support multi-RSU / cross-domain joint control and, combined with network slicing technology, ensure service continuity when vehicles move across domains at high speeds;

[0165] e) Both the roadside RSU and the vehicle-side OBU should support multi-mode communication protocol stacks, including Dedicated Short-Range Communications (DSRC) and Cellular Vehicle-to-Everything (C-V2X), to provide stronger service adaptability in heterogeneous networks;

[0166] f) Supports dynamic collaborative strategies based on artificial intelligence, which can dynamically optimize collaborative logic and communication resource scheduling strategies based on traffic flow status predictions, lane change success rate statistics, etc.

[0167] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not limiting. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention can be modified or replaced by equivalents without departing from the purpose and scope of the technical solutions, which should all be included in the scope of the claims of the present invention.

Claims

1. A hybrid network communication system for networked collaborative driving, characterized by: include: S1. Analyze straight road scenarios on urban highways and expressways, including scene composition and traffic flow. S2. Deploy RSU and MEC computing units based on scenario analysis; S3. Establish multi-mode communication and hybrid network topology; S4. Establish a hybrid network cooperative lane-changing communication system based on multi-mode communication and a hybrid network topology, which includes a vehicle-side system, a roadside system, and a cloud control platform; S5. Execute CAV collaborative lane-changing driving services based on a hybrid network collaborative lane-changing communication system.

2. A hybrid network communication system for networked collaborative driving according to claim 1, characterized in that: In step S2, based on the scenario analysis results of urban straight roads and highway straight roads, the deployment of RSU and MEC computing units includes basic requirements, RSU and MEC deployment requirements for sparsely distributed vehicle nodes, and RSU and MEC deployment requirements for densely distributed vehicle nodes. Basic requirements include: On straight sections of urban highways, the distance between each two adjacent RSUs is 200-500m, and a MEC computing unit is deployed near each RSU; on straight sections of expressways, the distance between each two adjacent RSUs is 500-1000m, and a MEC computing unit is deployed near each RSU; The deployment requirements for RSUs and MECs in sparsely distributed vehicle nodes include: on straight sections of urban highways, the distance between each two adjacent RSUs is 400-800m, and one MEC server manages multiple RSUs; on straight sections of expressways, the distance between each two adjacent RSUs is 1000-1500m, and one MEC server manages multiple RSUs; The RSU and MEC deployment requirements under densely distributed vehicle nodes include: on straight sections of urban highways, the distance between each two adjacent RSUs is 200-400m, and the number of RSUs managed by each MEC computing unit is 2 to 3; on straight sections of highways, the distance between each two adjacent RSUs is 400-800m, and the number of RSUs managed by each MEC computing unit is 2 to 3.

3. The hybrid network communication system for networked collaborative driving according to claim 1, characterized in that: In step S3, the communication nodes in the multi-mode communication and hybrid network topology include: cloud control platform, full coverage 5G base stations, RSU, MEC, and vehicles; vehicles include HDV and connected autonomous driving vehicles CAV; CAVs are divided into three types based on the communication mode: CAVs that support only PC5 direct communication, CAVs that support only Uu communication, and CAVs that support both PC5 direct communication and Uu communication. Multi-mode communication and hybrid network topology is a fusion structure composed of star, tree, and mesh structures, including: A. Connect vehicles with each RSU and each 5G base station as the center to obtain different star structures; B. With the cloud control platform as the root node and the RSU and MEC computing units as relay nodes, a hierarchical scheduling topology is constructed to obtain a tree structure. C. Vehicles with PC5 direct communication capabilities build a horizontal mesh structure through V2V.

4. The hybrid network communication system for networked collaborative driving according to claim 1, characterized in that: The cloud control platform collects and integrates data uploaded by vehicle-side and roadside systems to achieve global environment modeling and traffic situation awareness, and distributes high-precision maps. The roadside system includes 5G base stations, RSUs, and MEC computing units. These are used to cache high-precision maps issued by the cloud control platform and forward feedback information to the vehicle-side system. The RSUs sense and acquire local environmental information and upload it to the cloud control platform or MEC computing unit. The MEC computing unit is equipped with a collaborative control unit for lane change decision calculations, trajectory optimization, and emergency intervention control. The vehicle-side system includes HDV and CAV. HDV only exists as a perception object, while CAV is used to perceive vehicle information and, combined with feedback information from the roadside system, perform lane change trajectory planning, control command response, and local exception handling.

5. The hybrid network communication system for networked collaborative driving according to claim 1, characterized in that: The vehicle-side system is used to achieve autonomous networking and intelligent switching of communication paths between vehicles. A local collaborative control unit is deployed in the CAV to identify vehicle driving intentions and execute trajectory planning. The vehicle-side system uses a vehicle-side multi-mode communication method, including: PC5 priority mode: Vehicle nodes within the same coverage area communicate directly via PC5; Uu priority mode: Vehicle nodes that support both PC5 direct communication and Uu communication give priority to using the Uu interface to communicate with RSU and 5G base stations; Uu communication supplementary mode: cross-regional vehicle nodes communicate through 5G base station relays; Cross-network collaboration mode: Vehicle nodes that only support PC5 direct communication interact with vehicle nodes that only support Uu communication through RSU and 5G base stations; vehicle nodes that only support PC5 direct communication interact with vehicle nodes that support both PC5 direct communication and Uu communication through RSU; vehicle nodes that only support Uu communication interact with vehicle nodes that support both PC5 direct communication and Uu communication through 5G base stations; 5G base stations communicate and transmit with the cloud control platform through optical fiber connections.

6. A hybrid network communication system for networked collaborative driving according to claim 1, characterized in that: Based on the hybrid network cooperative lane change communication system, step S5 performs the CAV cooperative lane change driving service, including the following steps: A1. After the target CAV triggers a lane change intention, it first determines whether it is executable within its own OBU. If the judgment result is executable, the local collaborative control unit generates a lane change request based on the lane change intention, broadcasts the lane change request information to the neighboring CAVs, and simultaneously sends the lane change request information to the MEC computing unit through the RSU. A2. The collaborative control unit integrated into the MEC computing unit performs intention recognition based on cached data and generates collaborative lane change trajectory instructions; A3. Determine whether the target CAV is located in an RSU low coverage area. If so, execute step A4; if not, execute A5. A4. The MEC computing unit sends the coordinated lane change trajectory command to the target CAV. The local coordinated control unit of the target CAV selects a coordinated vehicle based on the coordinated lane change trajectory command and sends a coordinated lane change request to the coordinated vehicle via V2V communication. The coordinated vehicle returns a coordinated lane change response via V2V communication. The target CAV then sends a road control command to the coordinated vehicle, completing the coordinated lane change. A5. The collaborative control unit integrated in the MEC computing unit selects a collaborative vehicle and sends a collaborative lane change request to the collaborative vehicle through the RSU. The collaborative vehicle uploads a collaborative lane change response to the RSU. The MEC computing unit then sends a road control command to the collaborative vehicle, enabling the roadside to guide and control the collaborative vehicle and complete the collaborative lane change. A6. The target CAV reports the execution result to the MEC computing unit, which determines whether to trigger rescheduling or downgrade processing based on the execution result. In addition, the RSU receives and fuses the roadside perception data from the integrated radar and camera equipment and the vehicle-side perception data from the vehicle in real time, and then sends the fused data to the MEC computing unit for caching; the RSU regularly sends periodic services to the vehicle; when a CAV vehicle within the RSU range triggers a lane change condition, the periodic service information is not interrupted with the lane change trigger. While the collaborative lane change driving service is being executed, periodic service communications are still carried out between the RSU and the vehicle.

Images