C-V2X centralized communication method for cooperative lane change

Abstract

The invention relates to a C-V2X centralized communication method for cooperative lane change, and belongs to the field of Internet of Vehicles communication. The method comprises the following steps: analyzing urban straightway and expressway straightway scenes, including scene composition and scene traffic flow; deploying the roadside RSU communication equipment and the MEC computing unit according to the scene analysis result; establishing a cooperative lane changing service strategy under the guidance of a roadside RSU; establishing a multi-mode communication and centralized topological structure; establishing a V2X communication data flow before and after triggering the CAV collaborative lane changing driving service; and according to different coverage conditions of the roadside RSU, establishing a data interaction process of the CAV node under different coverage conditions. According to the method, the overlapped area of the communication range of the roadside equipment under uniform deployment is considered at the same time, the communication service continuity under the cross-domain condition is realized based on the cooperative lane changing communication service process, and the low delay and high reliability of the Internet of Vehicles communication are realized.

Description

Technical Field

[0001] The present invention belongs to the field of vehicle networking communications and relates to a C-V2X centralized communication method for cooperative lane changing. Background Art

[0002] With the commercialization of 5G communication technology and the rapid development of intelligent transportation systems, connected and automated vehicles (CAV) are gradually realizing multi-dimensional V2X communications covering vehicle to vehicle (V2V), vehicle to infrastructure (V2I), and vehicle to network (V2N).

[0003] Currently, traffic congestion is one of the main problems facing urban traffic. One of the important reasons for this situation is the unreasonable lane-changing behavior of drivers. As a basic operation in daily driving, lane changing involves the change of vehicles between two adjacent lanes. The purpose of lane changing is usually to ensure vehicle traffic efficiency and relieve traffic pressure. However, human-driven vehicles (HDVs) may perform some unreasonable lane-changing behaviors in order to protect their own interests, which may lead to traffic congestion and even traffic accidents.

[0004] Collaborative lane-changing service is an advanced assisted driving function of CAV. It can use V2X communication technology to realize real-time interaction of perception information and control information between vehicles, roads and clouds, thereby optimizing the lane-changing strategy of terminal vehicles, improving traffic efficiency, and reducing traffic congestion and accident rates.

[0005] However, although 5G technology provides communication guarantee for the realization of complex services with its high bandwidth, low latency and high reliability, the current C-V2X (Cellular Vehicle-to-Everything) architecture still has limitations in guiding the realization of collaborative driving tasks in complex traffic scenarios. The existing Internet of Vehicles communication architecture often lacks considerations for specific traffic scenarios and driving services. Most centralized communication architectures do not fully consider the impact of the performance and deployment of communication equipment on the communication architecture when designing, and rarely involve the requirements of specific driving services for the quality of the communication architecture. These problems limit the further improvement of the performance of the Internet of Vehicles communication system, especially when dealing with high-speed dynamic and complex and changeable networked vehicle collaborative driving services, the existing centralized communication architecture is not sufficient to play a regulatory role. Summary of the invention

[0006] In view of this, an object of the present invention is to provide a C-V2X centralized communication method for cooperative lane changing.

[0007] In order to achieve the above object, the present invention provides the following technical solutions:

[0008] A C-V2X centralized communication method for cooperative lane change, the method comprising the following steps:

[0009] S1. Establish urban straight road and highway straight road scenes, including scene composition and scene traffic flow;

[0010] S2. Deploy roadside RSU communication equipment and MEC computing units based on scenario analysis results;

[0011] S3. Establish a cooperative lane-changing service strategy guided by roadside RSU;

[0012] S4, establish multi-mode communication and centralized topology;

[0013] S5. Establishing V2X communication data flow before and after the CAV cooperative lane change driving service is triggered;

[0014] S6. According to the different coverage conditions of roadside RSU, establish the data interaction process of CAV nodes under different coverage conditions.

[0015] Further, in step S1, it includes:

[0016] S11. First, the components of the urban and highway straight road scenes include: car, road, and cloud.

[0017] Vehicle types are divided into human-driven vehicles HDV and connected autonomous vehicles CAV. For connected autonomous vehicles CAV, according to the communication mode of its on-board unit OBU, it is divided into: only supporting PC5 direct communication, only supporting 5G Uu communication, and supporting both PC5 direct connection and 5G Uu communication;

[0018] The road types are urban highway straight roads and expressway straight roads. The roadside facilities include basic facilities, monitoring equipment, and auxiliary communication equipment. Among them, the basic facilities include traffic signs, signal lights, traffic guardrails, and lighting equipment. The monitoring equipment is used to collect local road section information, including cameras, millimeter wave radars, and laser radars, which together form a radar-camera integrated device. The auxiliary communication equipment includes the roadside unit RSU, the edge computing unit MEC, and the 5G operator base station.

[0019] The cloud server is a data cloud platform that supports C-V2X services. The data cloud platform is used to store, calculate, and analyze basic information on the vehicle and road. The cloud platform provides various big data application services to the vehicle user end through 5G base stations, including high-precision map loading and local information distribution. At the same time, the cloud service platform provides monitoring of the C-V2X communication network status, including network load and connection quality.

[0020] S12. Secondly, for traffic flow in urban straight roads and highway straight roads, the following concepts are defined:

[0021] a) CAV node penetration rate: CAV node penetration rate refers to the proportion of CAV vehicles in a certain area to the total number of vehicles in the area. CAV node penetration rate is related to the deployment of vehicle terminals. The lower the CAV node penetration rate, the higher the uncertainty of traffic flow;

[0022] b) CAV dense / sparse nodes: The sparser the CAV nodes are, the higher the communication coverage requirement is; the denser the CAV nodes are, the higher the possibility of communication resource conflicts, channel congestion, and reduced signal-to-noise ratio is;

[0023] c) Traffic flow in urban straight road scenario: The maximum traffic flow density of the urban straight road section is selected as the traffic flow parameter of the section;

[0024] d) Traffic flow in highway straight road scenarios: For highway straight roads near highway intersections, a centralized communication architecture with dense nodes in urban straight roads is adopted; for highway straight roads away from highway intersections, a centralized communication architecture with sparse node distribution in highway straight road scenarios is adopted.

[0025] Further, in step S2, according to the urban straight road and highway straight road scenarios, the deployment of roadside RSU communication equipment and MEC computing units includes basic requirements, RSU and MEC deployment requirements for sparsely distributed vehicle nodes, and RSU deployment requirements for densely distributed vehicle nodes, wherein:

[0026] For basic requirements, in straight sections of highways, the spacing of RSUs is set with reference to the communication performance of RSUs and the high-speed mobility of vehicles in the section; in straight sections of cities, the spacing of RSUs is set with reference to equipment cost and performance to ensure the quality of V2I communication; for straight sections at intersections of highways and urban roads, RSUs are deployed at the center of the gantry or on the cross arm of the roadside pole close to the center of the lane, and the vertical height is set;

[0027] For RSU and MEC deployment under sparse distribution of vehicle nodes, the following strategies are adopted:

[0028] a) Deployment spacing: To ensure communication quality, increase the RSU deployment spacing, reduce the overall deployment quantity, and consider deploying one MEC to manage multiple RSUs;

[0029] b) Location selection: RSU and MEC are deployed in unobstructed locations on both sides of the road;

[0030] For RSU and MEC deployment under densely distributed vehicle nodes, the following strategies are adopted:

[0031] a) Deployment spacing: To ensure smooth V2I link channels and reduce the risk of resource constraints, the deployment spacing of RSUs is reduced, and one MEC is responsible for at most two RSUs;

[0032] b Location selection: RSU and MEC are deployed in unobstructed locations on both sides of the road;

[0033] c) Signal enhancement: The signal transmission power enhancement equipment corresponding to the deployment of RSU.

[0034] Furthermore, in step S3, the collaborative control algorithm of the cooperative lane changing task under roadside guidance is deployed in the V2X service platform of the roadside MEC or cloud server, and the lane changing intention, cooperative party identification and request involved in the CAV lane changing service are all calculated and given in the MEC, wherein the MEC can obtain vehicle information within the range through the roadside sensing device and estimate the driving intention of all vehicles through the intention recognition algorithm; based on the roadside sensing, communication and computing units, the roadside realizes centralized communication guidance of the cooperative lane changing service of the CAV node, which includes guidance strategies at the driving service level and the network communication level.

[0035] Further, in step S3, in the cooperative lane-changing strategy at the driving service level, the long-distance cooperative driving between the host vehicle HV and other CAVs is realized based on the roadside RSU traffic equipment and the MEC computing unit, which includes the following processes:

[0036] The roadside sensing equipment has a sensing range that includes a straight urban road with several lanes, as well as several HDVs and CAVs traveling straight;

[0037] Based on the fused perception information, MEC sequentially performs lane change intention recognition of the requesting party, identification and request of the collaborating party, path planning and vehicle control in the built-in roadside cooperative control unit.

[0038] Finally, MEC sends the collaborative control information to the collaborative node CAV within the communication range in real time through the I2V link of RSU.

[0039] Furthermore, in step S3, in the cooperative lane changing strategy at the network communication level, it has the following network constraints:

[0040] a) The operating frequency band of PC5 direct communication complies with the specified allocated frequency band;

[0041] b) PC5 direct communication supports many-to-many V2I communication services, and C-V2X supports broadcasting service information within the communication range. All vehicle-side OBUs in the area can receive messages sent by the roadside, and the maximum message sending frequency does not exceed the preset frequency;

[0042] c) The end-to-end communication delay and packet loss rate between the vehicle and the roadside unit within the communication range of C-V2X direct communication are both less than the corresponding set thresholds;

[0043] d) When the C-V2X roadside equipment supports one-to-many direct communication transmission, when the CAV node receives the signal from the RSU, the reference signal receiving power of the physical direct link shared channel is not less than the preset power, and the signal to interference plus noise ratio is not less than the preset value;

[0044] e) 5G network provides vehicle-to-cloud data interaction for vehicles, supports data transmission latency of 100 milliseconds, and both uplink and downlink transmission rates are not lower than the preset thresholds;

[0045] f) RSU and 5G base stations that support C-V2X communication are required to provide service continuity when vehicles cross domains.

[0046] Further, in step S4, the communication nodes in the multi-mode communication and centralized topology structure include: a fully covered operator 5G base station, a roadside communication unit RSU, a CAV supporting only 5G Uu communication, a CAV supporting only PC5 direct communication, and a CAV supporting both 5G Uu and PC5 direct communication, wherein vehicles supporting only PC5 communication are centrally dispatched through the roadside RSU, vehicles supporting only Uu communication are centrally dispatched only through the 5G base station, and vehicles supporting both PC5 and Uu communication are preferentially centrally dispatched through the roadside RSU;

[0047] The multi-mode communication and centralized topology presents a star or tree structure. The central node is the cloud control platform, and the centralized communication nodes are the roadside RSU and 5G base stations.

[0048] Further, in step S5, the specific process of the communication data and specific flow of the straight road cooperative lane change service under the centralized vehicle-road network communication is as follows:

[0049] 1) The MEC computing unit communicates with the RSU wirelessly through wired optical fiber and obtains the road fusion perception data from the roadside radar and vision integrated perception device, and the BSM and SSM uploaded by the vehicle domain controller through the OBU;

[0050] 2) The RCU integrated in the MEC performs intent recognition, collaborative party identification and confirmation on the uplink data in sequence, and then sends a collaborative lane change request VIR to the collaborative party's OBU through the RSU's PC5 direct communication. The collaborative party uploads a collaborative lane change response VIR to the RSU through the OBU's PC5 direct communication.

[0051] 3) After receiving the confirmation message from the collaborating party, MEC sends the road control command RSC to the OBU of the collaborating party through the PC5 direct communication of RSU;

[0052] 4) The OBU distributes the roadside control command RSC to the vehicle domain controller through the CAN bus, ultimately achieving the guidance and control of the cooperative vehicle by the roadside;

[0053] The communication process of CAV in normal driving on a straight road is as follows:

[0054] 1) When the CAV node in the straight-line scenario does not trigger the lane-changing condition, the RSU only transmits periodic services to the CAV, including RSM, SSM, MAP, SPAT, and RSI;

[0055] 2) When a CAV vehicle within the RSU range triggers a lane-changing condition, the CAV is identified as an HV, and the lane-changing service information is exchanged between the RSU and the OBU in the centralized communication architecture; and the periodic service information is not interrupted by the triggering of the collaborative lane-changing. While the collaborative lane-changing service information is being sent and received, the RSU and the OBU still perform periodic service communication.

[0056] Further, in step S6, the overlapping situations of the urban straight road RSU communication coverage include a single RSU coverage area, a double RSU coverage area, and a triple RSU coverage area, so the CAV lane changing process has three scenarios:

[0057] Scenario 1: The CAV lane-changing process is within the coverage of the same RSU; Scenario 2: The CAV lane-changing process is at the intersection of two RSU coverage areas; Scenario 3: The CAV lane-changing process is at the intersection of three RSU coverage areas;

[0058] Among them, in the first scenario, when the CAV triggers the lane change condition when it enters the RSU coverage area for the first time, the CAV is defined as an HV by the roadside end, and based on the cooperative lane change service strategy guided by the roadside RSU, it relies on the on-board OBU and the roadside RSU to realize the perception and control information interaction, and realizes the cooperative lane change process guided by the roadside;

[0059] In the second scenario, when the CAV drives to the intersection of the communication coverage areas of the two RSUs and generates the HV lane change intention, two types of situations are considered:

[0060] 1) The CAV enters the coverage of dual RSUs from the coverage of a single RSU:

[0061] At this time, CAV uploads BSM, SSM, and ISM collaborative driving service information to RSU_1 through OBU, and RCU sends VIR lane change request information to CAV through RSU_1; RSU_1 also transmits collaborative control command information RSC to RSU_2;

[0062] 2) The cooperative vehicle CAV enters the single RSU coverage area from the dual RSU coverage area:

[0063] When the CAV is in the overlapping area of ​​dual RSU communication coverage but only within the sensing range of RSU_1, RSU_1 will receive the sensing information SSM and vehicle status information BSM within the received range and transmit it to the roadside cooperative control unit RCU_2 at RSU_2 through optical fiber for algorithm processing; when the CAV is in the overlapping area of ​​dual RSU communication coverage and enters the sensing range of RSU_2, the roadside sensing information SSM and vehicle status information BSM are transmitted from RSU_2 to RCU_2, and the request instruction VIR and control instruction RSC are sent to the CAV through RSU_2;

[0064] When entering the coverage of a single RSU_2, the communication process of the first scenario is adopted;

[0065] In the third scenario, the roadside cooperative control unit RCU_2, which is closest to the lane-changing vehicle HV, is used to issue control instructions to the CAV; when just entering the three-RSU coverage area, the vehicle status information BSM, the intention sharing information ISM and the perception information of the previous roadside RSU_1 are all transmitted from RSU_1 to RSU_2, and then transmitted to RCU_2 for roadside calculation; within the three-RSU coverage area, the above information is received by RSU_2 and uploaded to RCU_2 for calculation; when the vehicle is about to exit the overlapping area of ​​the three RSU communication coverage, the roadside information will be transmitted from RSU_2 to RSU_3, and its communication process will be transformed into the second scenario, thereby completing the lane change service.

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

[0067] The present invention is specifically aimed at realizing the cooperative lane-changing service of CAV in the urban straight road scenario, and designs the communication architecture elements including the deployment scheme of roadside equipment and edge computing units, the communication data interaction process and the communication node topology structure, and considers the execution of the cooperative lane-changing service under different communication coverage conditions of RSU involving the on-board units with different communication interfaces directly connected to 5G Uu and PC5. The present invention is committed to realizing the guidance of vehicles to perform cooperative lane-changing services under the centralized communication architecture.

[0068] The present invention optimizes the design of the traditional centralized communication architecture. The present invention is universal in realizing networked collaborative driving services for CAVs in urban and high-speed straight road scenarios, and is particularly instructive for collaborative lane changing services.

[0069] Other advantages, objectives and features of the present invention will be described in the following description to some extent, and to some extent, will be obvious to those skilled in the art based on the following examination and study, or can be taught from the practice of the present invention. The objectives and other advantages of the present invention can be realized and obtained through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] 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 in conjunction with the accompanying drawings, wherein:

[0071] Figure 1 Schematic diagram of the centralized C-V2X communication architecture for straight roads in the city;

[0072] Figure 2 This is a schematic diagram of the RSU deployment solution for the straight-line scenario;

[0073] Figure 3 A schematic diagram of a cooperative lane change scenario on a straight road in an urban area;

[0074] Figure 4 Schematic diagram of the topological structure of vehicle nodes in different communication modes under the centralized communication architecture;

[0075] Figure 5 It is a schematic diagram of the data flow of cooperative lane-changing communication under the guidance of the urban straight road side;

[0076] Figure 6 The overall communication process diagram of CAV under the C-V2X centralized communication architecture on urban straight roads;

[0077] Figure 7 A schematic diagram of the communication coverage overlap area after RSU deployment;

[0078] Figure 8 A schematic diagram of a CAV performing a cooperative lane change within the coverage area of ​​an RSU;

[0079] Fig. 9 A schematic diagram of a CAV entering a dual RSU coverage area from a single RSU coverage area;

[0080] Fig.10 A schematic diagram of a CAV entering a single RSU coverage area from a dual RSU coverage area;

[0081] Fig.11The CAV can perform cooperative lane changing in the overlapping area of ​​three RSU communication coverage. DETAILED DESCRIPTION

[0082] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments only illustrate the basic concept of the present invention in a schematic manner, and the following embodiments and features in the embodiments can be combined with each other without conflict.

[0083] Among them, the drawings are only used for illustrative explanations, and they only represent schematic diagrams rather than actual pictures, and should not be understood as limitations on the present invention. In order to better illustrate the embodiments of the present invention, some parts of the drawings may be omitted, enlarged or reduced, and do not represent the size of actual products. For those skilled in the art, it is understandable that some well-known structures and their descriptions in the drawings may be omitted.

[0084] The same or similar numbers in the drawings of the embodiments of the present invention correspond to the same or similar parts; in the description of the present invention, it should be understood that if the terms "upper", "lower", "left", "right", "front", "rear", etc. indicate the orientation or position relationship, they are based on the orientation or position relationship shown in the drawings, which is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operate in a specific orientation. Therefore, the terms describing the position relationship in the drawings are only used for illustrative purposes and cannot be understood as limiting the present invention. For ordinary technicians in this field, the specific meanings of the above terms can be understood according to specific circumstances.

[0085] See also Figures 1 to 11 , which is a C-V2X centralized communication method for cooperative lane changing.

[0086] Please refer to Figure 1 , which is a centralized communication architecture specifically designed by the present invention for cooperative lane-changing services in straight-line scenarios. This architecture not only considers the deployment of roadside equipment in actual traffic scenarios, but also involves the communication process of vehicle-mounted communication devices with different communication interfaces directly connected to 5G Uu and PC5, and supplements and optimizes the existing centralized communication architecture in terms of scenarios and services. According to the two major parts mentioned in the content of the present invention, the following will sequentially explain the detailed steps of the deployment of communication equipment in the cooperative lane-changing scenario and the communication part of the cooperative lane-changing service.

[0087] (1) Communication equipment deployment for cooperative lane-changing scenarios:

[0088] S1. Traffic scene analysis:

[0089] S11. Traffic scene composition

[0090] The scene involved in the present invention includes three components: car, road and cloud. Figure 1 The following is a detailed description of the components of the scene.

[0091] a) The vehicles are mainly passenger cars and commercial buses. The vehicle types are divided into human-driven vehicles (HDVs) and connected autonomous driving vehicles (CAVs). The on-board OBU communication modes of CAVs include: only supporting PC5 direct connection, only supporting 5G Uu communication, and supporting both PC5 and 5G Uu dual-mode communication;

[0092] b) The roads are Class III and above, and the road sections are straight sections, including straight highways and urban highways. The basic roadside facilities include traffic signs, signal lights, traffic guardrails, lighting equipment, etc. The roadside facilities supporting the Internet of Vehicles function include: integrated radar and camera equipment (camera, millimeter wave radar, laser radar, etc.) to collect local road section information; roadside units RSU that support vehicle-road communication; edge computing units MEC that integrate, analyze and control local vehicle-road data; and 5G operator base stations with full communication coverage.

[0093] c) The cloud server is mainly a cloud platform of domestic operators, with a data platform supporting C-V2X services added internally. The cloud platform is responsible for the storage, calculation and analysis of big data of basic information on the vehicle and road sides; the cloud platform can provide various big data application services for vehicle users through 5G base stations, including high-precision map loading, local information distribution, etc. At the same time, the cloud service platform provides monitoring of the C-V2X communication network status, including network load, connection quality, etc.

[0094] S12. Traffic flow analysis

[0095] a) CAV node penetration analysis: CAV node penetration refers to the proportion of CAV vehicles in a certain area to the total number of vehicles in the area. CAV node penetration is closely related to the deployment of vehicle terminals. When the CAV node penetration is low, the unreasonable driving behavior of HDV is likely to cause traffic congestion and traffic accidents; when the CAV node penetration increases, it helps reduce the uncertainty in traffic flow and improves traffic efficiency and traffic flow stability.

[0096] b) Analysis of the impact of dense / sparse node access on network communication: When CAV nodes are sparsely distributed, network capacity rarely reaches saturation, but sparse distribution has high requirements for communication coverage. In order to ensure the continuity of communication services, reasonable base station and roadside RSU deployment is key; when CAV nodes are too dense, high-density node access can increase network capacity, but it may also cause communication resource conflicts, channel congestion, and reduced signal-to-noise ratio, affecting network performance. Therefore, a suitable communication architecture is conducive to the scheduling of communication resources and is conducive to guiding CAVs to achieve collaborative driving services in complex scenarios.

[0097] c) Analysis of traffic flow changes in urban straight road scenarios: For urban straight road scenarios, the traffic density is relatively large, especially in urban main roads during peak hours in the morning and evening, where traffic congestion is prone to occur. For such straight road sections, the present invention will use the maximum traffic density of the section as a reference for designing a centralized communication architecture; while for some non-main roads in the suburbs, the traffic density is usually low. At this time, the present invention will design the communication architecture according to the situation of sparse nodes.

[0098] d) Analysis of traffic flow changes in highway straight road scenarios: (dense situation, sparse situation) For highway straight road scenarios, the traffic density is usually small. For straight roads near highway intersections, there are usually congestion such as queues at toll booths. At this time, the present invention will consider using a centralized communication architecture with dense nodes on urban straight roads. For straight road sections of highways far away from urban areas, the vehicle speed is fast and congestion is not easy to occur. The present invention will consider using a centralized communication architecture with sparse node distribution for highway straight road scenarios.

[0099] S2. Deploy roadside V2X communication equipment, including general requirements and specific requirements. This embodiment provides a deployment example, such as Figure 2 shown.

[0100] S21. General requirements for RSU deployment:

[0101] In order for connected vehicles to safely and reliably exchange information with base stations and roadside terminals during high-speed movement, the quality of V2I communication needs to be reliably guaranteed. The effective communication distance of roadside RSU communication equipment is usually 500-800m. The present invention considers 500m as the reference value of the effective communication radius of RSU. Figure 2 shown.

[0102] a) On straight sections of highways, there are usually no tall buildings or vegetation to block or interfere with signals. Considering the communication performance of RSU and the high-speed mobility of vehicles on the road, the spacing is set to 400-600m.

[0103] b) On straight sections of urban roads, there are usually a large number of tall buildings and vegetation that cause obstruction and signal interference, and the deployment spacing of RSU communication equipment needs to be further reduced to ensure the quality of V2I communication. However, considering the equipment cost and performance, the minimum spacing can be set to 400m.

[0104] c) For highways and urban straight roads, in order to ensure that the communication quality of vehicles traveling in both directions is as consistent as possible and reduce line-of-sight obstruction, the RSU is usually deployed at the center of the gantry or on the cross arm of the roadside pole close to the center of the lane, with a vertical height of ≥5m.

[0105] The deployment requirements for RSU and MEC in different situations are as follows:

[0106] S22. RSU and MEC deployment under sparse distribution of vehicle nodes:

[0107] In areas where vehicle nodes are sparsely distributed, such as straight roads in rural or suburban areas, the distance between vehicles is large, so the deployment of RSUs can adopt the following strategies:

[0108] a) Deployment spacing: Due to the sparse number of vehicles, the deployment spacing between RSUs can be appropriately increased to reduce the overall deployment quantity and cost. The recommended deployment spacing is 600-800 meters to ensure proper communication coverage between vehicles. At the same time, due to the small number of CAV nodes on the road section, the computing resources required are relatively small, so it can be considered that one MEC is responsible for the computing resources of 2-3 CAV communication nodes within the coverage of RSU.

[0109] b) Location selection: RSU and MEC should be deployed in obvious locations on both sides of the road, such as on roadside poles, to reduce signal obstruction caused by terrain or vegetation.

[0110] S23. RSU deployment under densely distributed vehicle nodes:

[0111] In areas where vehicle nodes are densely distributed, such as commercial areas in the city center and congested sections of urban main roads. In this section, the distance between vehicles is small, so the vehicle density is large. At the same time, the traffic volume on this section is large. Considering the frequent access of dense nodes and the easy limitation of communication resources, it is necessary to increase the number of RSU deployments within the range. The present invention increases the RSU communication node and MEC deployment density by reducing the deployment spacing, thereby ensuring CAV's requirements for low communication latency and low packet loss rate. The deployment strategy is as follows:

[0112] a) Deployment spacing: Vehicles are densely populated. To ensure smooth V2I link channels and reduce the risk of resource constraints, it is recommended to set the RSU deployment spacing to 300-400 meters. At the same time, consider that MEC is responsible for the computing resources of CAV communication nodes within the coverage of 1-2 RSUs.

[0113] b) Location selection: RSU and MEC should be deployed in obvious locations on both sides of the road, such as on roadside poles, to reduce signal obstruction caused by terrain or vegetation.

[0114] c) Signal enhancement: In these areas, it may be necessary to enhance the signal transmission power of the RSU, which can improve the communication range of the RSU while alleviating the impact of obstacles such as urban buildings on signal weakening.

[0115] (2) Collaborative lane-changing service communication part:

[0116] S3. Analysis of cooperative lane-changing service under roadside guidance:

[0117] The collaborative control algorithm involved in the application service of the present invention is deployed in the V2X service platform of the roadside MEC or cloud server, and the lane changing intention, collaborative party identification and request involved in the CAV lane changing service are all calculated in the MEC, where the MEC can obtain vehicle information within the range through the roadside sensing device and estimate the driving intention of all vehicles through the intention recognition algorithm. Based on the roadside sensing, communication and computing units, the centralized communication guidance of the roadside to the CAV node collaborative lane changing service is realized, which requires not only a clear process of the collaborative lane changing driving service, but also the low latency and high reliability required by the driving service for network communication. The following will analyze the collaborative lane changing service under roadside guidance from the driving service level and the network communication level.

[0118] S31, collaborative lane changing, i.e., when the host vehicle (HV) equipped with the networked communication device OBU triggers the lane changing condition during driving (i.e., there is congestion in front of the lane and there are no oncoming vehicles in the safety area behind the adjacent lane), it notifies the surrounding CAVs of the vehicle's lane changing intention and requests the surrounding CAVs to assist it in switching to the adjacent lane, thereby improving road traffic efficiency.

[0119] The cooperative lane change under roadside guidance is based on the roadside RSU traffic equipment and MEC computing unit to achieve cooperative driving between HV and CAV within a larger communication range. Figure 3As shown in the figure, the perception range of the roadside sensing equipment (including cameras, millimeter wave radars, laser radars, etc.) includes a 320m urban straight road (three lanes) and 11 HDVs and 3 CAVs going straight. Assume that at the current moment, CAVs (CAV_5, HV_6, CAV_7) are on three different straight roads. Based on the fused perception information (vehicle type, yaw angle, speed, etc.), MEC sequentially performs lane change intention recognition of the requester, identification and request of the collaborating party, path planning and vehicle control in the embedded roadside collaborative control unit (RCU). Finally, MEC sends the collaborative control information to the collaborative node CAV within the communication range in real time through the I2V (Infrastructure to Vehicle) link of RSU. Based on the above situation, the roadside end first controls CAV_5 to appropriately reduce the speed and increase the distance with the front vehicle HDV_9 to form a collaborative lane change area to ensure that HV_6 changes lanes safely and efficiently, and then controls CAV_7 to switch to lane 2 to complete the roadside-guided collaborative lane change. In addition, the selection of HV will involve the priority determination of the collaborative control unit (Roadside Control Unit, RCU) within the MEC, and the completion of the roadside guided lane change service also involves the execution of the planning control algorithm within the RCU.

[0120] S32. When vehicles are moving at high speeds, they need to implement cooperative lane-changing services, which places more stringent demands on C-V2X communications. To ensure the security and smoothness of the services, the following requirements must be met:

[0121] a) The operating frequency band of PC5 direct communication should comply with the 5905-5925MHz allocated by the Ministry of Industry and Information Technology;

[0122] b) PC5 direct communication should support many-to-many V2I communication services. C-V2X supports broadcasting of service information within the communication range. All vehicle-side OBUs in the area can receive messages sent by the roadside. The maximum message sending frequency is ≤100Hz;

[0123] c) C-V2X direct communication requires that the end-to-end communication delay between vehicle and road within the communication range under large-scale application scenarios is less than 50ms and the packet loss rate is less than 10%;

[0124] d) C-V2X roadside equipment should support one-to-many direct communication transmission. When the CAV node receives the signal from the RSU, the reference signal received power (PSRP) of the physical sidelink shared channel (PSSCH) is required to be no less than -108dBm, and the signal to interference plus noise ratio (SINR) is required to be no less than 5dB;

[0125] e) 5G network provides vehicle-to-cloud data interaction for vehicles, supports data transmission latency of 100 milliseconds, uplink transmission rate ≥ 20Mbps, and downlink transmission rate ≥ 200Mbps;

[0126] f) RSUs and 5G base stations that support C-V2X communication are required to provide service continuity when vehicles cross domains to reduce communication delays, information interruptions and redundancy caused by cross domains;

[0127] S4, multi-mode communication and centralized topology:

[0128] Currently, the existing OBUs on the market can include a variety of communication interfaces. Among them, PC5 direct communication and Uu cellular network communication are the main communication interfaces involved in V2X communication. The present invention is applicable to CAV nodes that include two communication interfaces, 5G Uu or PC5 direct connection. Among them, PC5 direct communication can provide short-distance, high-speed end-to-end communication, and is mostly used for communication between OBU and OBU, OBU and RSU in V2X; Uu interface is a vehicle network communication method realized by base station, mainly through wireless network connection, to realize data transmission between vehicles, road infrastructure and other equipment. The Uu interface can provide higher communication quality and larger transmission bandwidth within the coverage range, and is mostly used for communication between RSU and base station, OBU and base station.

[0129] Based on the RSU communication equipment deployment solution for the S2 straight road scenario, the communication nodes in the scenario include: fully covered operator 5G base stations, roadside communication units RSU, CAVs that only support 5G Uu communication, CAVs that only support PC5 direct communication, and CAVs that support both 5G Uu and PC5 direct communication. Therefore, vehicles that only support PC5 communication consider centralized scheduling through the roadside RSU, vehicles that only support Uu communication only consider centralized scheduling through 5G base stations, and vehicles that support both PC5 and Uu communication give priority to centralized scheduling by roadside RSU. This topology presents a star or tree structure, such as Figure 4 As shown in the figure, the central node is the cloud control platform, and the centralized communication nodes are the roadside RSU and 5G base stations.

[0130] S5, cooperative lane-changing communication data flow

[0131] Below, based on the S3 cooperative lane changing service analysis and the S4 multi-mode communication topology structure analysis, the communication data and specific flow of the straight-line cooperative lane changing service under the centralized vehicle-road network communication are introduced in detail.

[0132] Since the bandwidth of C-V2X is only 20MHz, C-V2X communication does not allow large raw data to be shared between communication devices. C-V2X usually uses the J2735 message standard to transmit information. C-V2X uses these message standards at the application layer to support efficient interaction between V2X devices. Based on the current message set standards, the vehicle-road-cloud uplink and downlink service messages for cooperative lane changing are mainly shown in Table 1. Among them, the communication links I2N (Infrastructure to Network) and N2I (Network to Infrastructure) mainly involve the cloud synchronization of vehicle-road information and the cloud delivery of messages such as high-precision maps and traffic light phases.

[0133] Table 1

[0134]

[0135] Based on the RSU deployment solution in the previous step, the effective communication radius of RSU in the urban straight road scenario is ≤500m. Within the effective communication coverage of RSU, the vehicle-road communication and interaction information involved in the coordinated lane change of the three CAVs are as follows: Figure 5 The specific steps of roadside guided cooperative lane change involving vehicle-road communication are as follows:

[0136] 1) The MEC computing unit communicates with the RSU wirelessly through wired optical fiber and obtains the road fusion perception data from the roadside radar and vision integrated perception device, and the BSM and SSM uploaded by the vehicle domain controller through the OBU;

[0137] 2) The RCU integrated in the MEC performs intent recognition, collaboration party identification and confirmation on the uplink data in sequence. Then, it sends a collaborative lane change request VIR to the collaboration party's OBU through the RSU's PC5 direct communication, and the collaboration party uploads a collaborative lane change response VIR to the RSU through the OBU's PC5 direct communication;

[0138] 3) After receiving the confirmation message from the collaborating party, MEC sends the road control command RSC to the OBU of the collaborating party through the PC5 direct communication of RSU;

[0139] 4) The OBU distributes the roadside control command RSC to the vehicle domain controller through the CAN bus, ultimately achieving the guidance and control of the cooperative vehicle by the roadside.

[0140] According to the traffic scenario and driving business analysis, lane changing business will only be generated when the CAV in the straight road scenario triggers the lane changing condition (that is, the front of the lane is congested and there are no oncoming vehicles in the safety area behind the adjacent lane), and then the CAV is coordinated through the roadside RSU and MEC. Considering the normal driving of CAV in the straight road scenario and the cooperative lane changing, the communication business in the centralized architecture is divided into periodic communication processes for supporting CAV straight road driving and business communication processes for supporting CAV cooperative lane changing, such as Figure 6 shown.

[0141] 1) When the CAV node in the straight-line scenario does not trigger the lane-changing condition, the RSU only transmits some periodic services to the CAV, including RSM, SSM, MAP, SPAT, RSI, etc.;

[0142] 2) When a CAV vehicle within the RSU range triggers a lane change condition, the CAV is identified as an HV, and the lane change service information exchange (including BSM, RSM, VIR, RSC, etc.) is performed between the RSU and OBU in the centralized communication architecture. It is worth noting that the periodic service information will not be interrupted due to the triggering of cooperative lane change. While the cooperative lane change service information is being sent and received, periodic service communication will also be performed between the RSU and OBU.

[0143] S6. CAV cross-region communication process when the communication coverage of RSUs on urban straight roads overlaps

[0144] According to the research on the commonly used RSU communication equipment in the market, it is known that the effective communication radius of RSU is about 500m. In the actual urban straight road scenario, in order to ensure the continuity of the communication coverage area and taking into account the high-speed mobility of vehicles, RSU adopts a uniform deployment scheme, and the deployment spacing is set to 400m. Therefore, in such a deployment, there will be a single RSU coverage area (400m), a dual RSU coverage area (400m) and a triple RSU coverage area (200m), such as Figure 7 shown.

[0145] a) Scenario 1: The CAV is within the coverage of the same RSU during the lane change process

[0146] like Figure 8 As shown in the figure, when the CAV enters the RSU coverage area for the first time (effective communication radius is 500m), the lane change condition is triggered. At this time, only one RSU can communicate with the CAV, that is, a single RSU scenario. At this time, the CAV is defined as an HV by the roadside end, and based on step S3, it relies on the on-board OBU to interact with the roadside RSU to realize the cooperative lane change process under the guidance of the roadside.

[0147] b) Scenario 2: The CAV is changing lanes at the intersection of two RSU coverage areas

[0148] During straight-line driving, cooperative lane-changing driving operations usually occur randomly in the congested area of ​​the lanes on the straight road. Therefore, when the CAV drives to the intersection area (400m) of the communication coverage of two RSUs and generates the HV lane-changing intention, two types of situations can be considered:

[0149] 1) The cooperative vehicle CAV enters the coverage of dual RSUs from the coverage of a single RSU, such as Fig. 9 shown.

[0150] At this time, CAV uploads (PC5, broadcast) BSM, SSM, ISM collaborative driving service information to RSU_1 through OBU, and RCU sends (PC5, broadcast) VIR lane change request information to CAV through RSU_1. It is worth noting that at this time, in order to ensure that CAV can complete collaborative driving services safely and efficiently in the overlapping area, RSU_1 is required to simultaneously transmit (optical fiber) collaborative control command information RSC to RSU_2, thereby ensuring that the information flow of CAV PC5 communication is switched from RSU_1 to RSU_2 without interruption.

[0151] 2) The cooperative vehicle CAV enters the single RSU coverage area from the dual RSU coverage area, e.g. Fig.10 shown.

[0152] When the CAV is in the overlapping area of ​​dual RSU communication coverage but only within the perception range of RSU_1, RSU_1 will receive the perception information SSM and vehicle status information BSM received within the range, and transmit it to the roadside cooperative control unit RCU_2 at RSU_2 through optical fiber (TCP) for algorithm processing. When the CAV is in the overlapping area of ​​dual RSU communication coverage and enters the perception range of RSU_2, the roadside perception information SSM and vehicle status information BSM are transmitted by RSU_2 (TCP) to RCU_2, and the request instruction VIR and control instruction RSC are sent to the CAV through RSU_2 (PC5, broadcast). When entering the coverage range of a single RSU_2, the communication process of scenario 1 is adopted.

[0153] a) Scenario 3: The CAV is at the intersection of three RSU coverage areas during lane change

[0154] According to the RSU deployment plan, there will be a 100m overlapping area of ​​three RSU communication coverage, such as Fig.11As shown. Considering that the vehicle is closest to RSU_2, the roadside collaborative control unit RCU_2 should be used to issue control instructions to the CAV (PC5, broadcast). When just entering the three-RSU coverage area, the vehicle status information BSM, the intention sharing information ISM, and the roadside RSU_1 perception information are all transmitted (optical fiber) from RSU_1 to RSU_2 and transmitted (optical fiber) to RCU_2 for roadside calculation; within the three-RSU coverage area, the above information is received by RSU_2 (optical fiber) and uploaded to RCU_2 for calculation; when the vehicle is about to exit the overlapping area of ​​the three RSU communication coverage, the roadside information will be transmitted (optical fiber) from RSU_2 to RSU_3, thereby ensuring the continuity of the roadside information. This process refers to scenario 2.

[0155] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. 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 solution of the present invention can be modified or replaced by equivalents without departing from the purpose and scope of the technical solution, which should be included in the scope of the claims of the present invention.

Claims

1. A C-V2X centralized communication method for cooperative lane changing, characterized by: The method comprises the following steps: S1. Analyze the straight road scenes in the city and on the highway, including the scene composition and scene traffic flow; S2. Deploy roadside RSU communication equipment and MEC computing units based on scenario analysis results; S3. Establish a cooperative lane-changing service strategy guided by roadside RSU; S4, establish multi-mode communication and centralized topology; S5. Establishing V2X communication data flow before and after the CAV cooperative lane change driving service is triggered; S6. According to the different coverage conditions of roadside RSU, establish the data interaction process of CAV nodes under different coverage conditions.

2. A C-V2X centralized communication method for cooperative lane changing according to claim 1, characterized in that: In step S1, it includes: S11. First, the components of the urban and highway straight road scenes include: car, road, and cloud. Vehicle types are divided into human-driven vehicles HDV and connected autonomous vehicles CAV. For connected autonomous vehicles CAV, according to the communication mode of its on-board unit OBU, it is divided into: only supporting PC5 direct communication, only supporting 5G Uu communication, and supporting both PC5 direct connection and 5G Uu communication; The road types are urban highway straight roads and expressway straight roads. The roadside facilities include basic facilities, monitoring equipment, and auxiliary communication equipment. Among them, the basic facilities include traffic signs, signal lights, traffic guardrails, and lighting equipment. The monitoring equipment is used to collect local road section information, including cameras, millimeter wave radars, and laser radars, which together form a radar-camera integrated device. The auxiliary communication equipment includes the roadside unit RSU, the edge computing unit MEC, and the 5G operator base station. The cloud server is a data cloud platform that supports C-V2X services. The data cloud platform is used to store, calculate, and analyze basic information on the vehicle and road. The cloud platform provides various big data application services to the vehicle user end through 5G base stations, including high-precision map loading and local information distribution. At the same time, the cloud service platform provides monitoring of the C-V2X communication network status, including network load and connection quality. S12. Secondly, for traffic flow in urban straight roads and highway straight roads, the following concepts are defined: a) CAV node penetration rate: CAV node penetration rate refers to the proportion of CAV vehicles in a certain area to the total number of vehicles in the area. CAV node penetration rate is related to the deployment of vehicle terminals. The lower the CAV node penetration rate, the higher the uncertainty of traffic flow; b) CAV dense / sparse nodes: The sparser the CAV nodes are, the higher the communication coverage requirement is; the denser the CAV nodes are, the higher the possibility of communication resource conflicts, channel congestion, and reduced signal-to-noise ratio is; c) Traffic flow in urban straight road scenario: The maximum traffic flow density of the urban straight road section is selected as the traffic flow parameter of the section; d) Traffic flow in highway straight road scenarios: For highway straight roads near highway intersections, a centralized communication architecture with dense nodes in urban straight roads is adopted; for highway straight roads away from highway intersections, a centralized communication architecture with sparse node distribution in highway straight road scenarios is adopted.

3. A C-V2X centralized communication method for cooperative lane changing according to claim 2, characterized in that: In step S2, according to the urban straight road and highway straight road scenarios, the deployment of roadside RSU communication equipment and MEC computing units includes basic requirements, RSU and MEC deployment requirements for sparsely distributed vehicle nodes, and RSU deployment requirements for densely distributed vehicle nodes, where: For basic requirements, in straight sections of highways, the spacing of RSUs is set with reference to the communication performance of RSUs and the high-speed mobility of vehicles in the section; in straight sections of cities, the spacing of RSUs is set with reference to equipment cost and performance to ensure the quality of V2I communication; for straight sections at intersections of highways and urban roads, RSUs are deployed at the center of the gantry or on the cross arm of the roadside pole close to the center of the lane, and the vertical height is set; For RSU and MEC deployment under sparse distribution of vehicle nodes, the following strategies are adopted: a) Deployment spacing: To ensure communication quality, increase the RSU deployment spacing, reduce the overall deployment quantity, and consider deploying one MEC to manage multiple RSUs; b) Location selection: RSU and MEC are deployed in unobstructed locations on both sides of the road; For RSU and MEC deployment under densely distributed vehicle nodes, the following strategies are adopted: a) Deployment spacing: To ensure smooth V2I link channels and reduce the risk of resource constraints, the deployment spacing of RSUs is reduced, and one MEC is responsible for at most two RSUs; b Location selection: RSU and MEC are deployed in unobstructed locations on both sides of the road; c) Signal enhancement: The signal transmission power enhancement equipment corresponding to the deployment of RSU.

4. The C-V2X centralized communication method for cooperative lane change according to claim 3, characterized in that: In step S3, the cooperative control algorithm of the cooperative lane-changing task under roadside guidance is deployed in the V2X service platform of the roadside MEC or cloud server. The lane-changing intention, cooperative party identification and request involved in the CAV lane-changing service are calculated in the MEC, where the MEC can obtain vehicle information within the range through the roadside sensing device and estimate the driving intention of all vehicles through the intention recognition algorithm; Based on the roadside perception, communication and computing units, the centralized communication guidance of the roadside to the CAV node cooperative lane changing service is realized, which includes the guidance strategies at the driving service level and the network communication level.

5. The C-V2X centralized communication method for cooperative lane change according to claim 4, characterized in that: In step S3, in the cooperative lane-changing strategy at the driving service level, the long-distance cooperative driving between the host vehicle HV and other CAVs is realized based on the roadside RSU traffic equipment and the MEC computing unit, which includes the following processes: The roadside sensing equipment has a sensing range that includes a straight urban road with several lanes, as well as several HDVs and CAVs traveling straight; Based on the fused perception information, MEC sequentially performs lane change intention recognition of the requesting party, identification and request of the collaborating party, path planning and vehicle control in the built-in roadside cooperative control unit. Finally, MEC sends the collaborative control information to the collaborative node CAV within the communication range in real time through the I2V link of RSU.

6. A C-V2X centralized communication method for cooperative lane change according to claim 5, characterized in that: In step S3, in the cooperative lane changing strategy at the network communication level, it has the following network constraints: a) The operating frequency band of PC5 direct communication complies with the specified allocated frequency band; b) PC5 direct communication supports many-to-many V2I communication services, and C-V2X supports broadcasting service information within the communication range. All vehicle-side OBUs in the area can receive messages sent by the roadside, and the maximum message sending frequency does not exceed the preset frequency; c) The end-to-end communication delay and packet loss rate between the vehicle and the roadside unit within the communication range of C-V2X direct communication are both less than the corresponding set thresholds; d) When the C-V2X roadside equipment supports one-to-many direct communication transmission, when the CAV node receives the signal from the RSU, the reference signal receiving power of the physical direct link shared channel is not less than the preset power, and the signal to interference plus noise ratio is not less than the preset value; e) 5G network provides vehicle-to-cloud data interaction for vehicles, supports data transmission latency of 100 milliseconds, and both uplink and downlink transmission rates are not lower than the preset thresholds; f) RSU and 5G base stations that support C-V2X communication are required to provide service continuity when vehicles cross domains.

7. The C-V2X centralized communication method for cooperative lane change according to claim 4, characterized in that: In step S4, the communication nodes in the multi-mode communication and centralized topology include: a fully covered operator 5G base station, a roadside communication unit RSU, a CAV that only supports 5G Uu communication, a CAV that only supports PC5 direct communication, and a CAV that supports both 5G Uu and PC5 direct communication, wherein vehicles that only support PC5 communication are centrally dispatched through the roadside RSU, vehicles that only support Uu communication are centrally dispatched only through the 5G base station, and vehicles that support both PC5 and Uu communication are preferentially centrally dispatched through the roadside RSU; The multi-mode communication and centralized topology presents a star or tree structure. The central node is the cloud control platform, and the centralized communication nodes are the roadside RSU and 5G base stations.

8. The C-V2X centralized communication method for cooperative lane change according to claim 7, characterized in that: In step S5, the specific process of the communication data and specific flow of the straight-track cooperative lane-changing service under the centralized vehicle-road network communication is as follows: 1) The MEC computing unit communicates with the RSU wirelessly through wired optical fiber and obtains the road fusion perception data from the roadside radar and vision integrated perception device, and the BSM and SSM uploaded by the vehicle domain controller through the OBU; 2) The RCU integrated in the MEC performs intent recognition, collaborative party identification and confirmation on the uplink data in sequence, and then sends a collaborative lane change request VIR to the collaborative party's OBU through the RSU's PC5 direct communication. The collaborative party uploads a collaborative lane change response VIR to the RSU through the OBU's PC5 direct communication. 3) After receiving the confirmation message from the collaborating party, MEC sends the road control command RSC to the OBU of the collaborating party through the PC5 direct communication of RSU; 4) The OBU distributes the roadside control command RSC to the vehicle domain controller through the CAN bus, ultimately achieving the guidance and control of the cooperative vehicle by the roadside; The communication process of CAV in normal driving on a straight road is as follows: 1) When the CAV node in the straight-line scenario does not trigger the lane-changing condition, the RSU only transmits periodic services to the CAV, including RSM, SSM, MAP, SPAT, and RSI; 2) When a CAV vehicle within the RSU range triggers a lane-changing condition, the CAV is identified as an HV, and the lane-changing service information is exchanged between the RSU and the OBU in the centralized communication architecture; and the periodic service information is not interrupted by the triggering of the collaborative lane-changing. While the collaborative lane-changing service information is being sent and received, the RSU and the OBU still perform periodic service communication.

9. The C-V2X centralized communication method for cooperative lane change according to claim 8, characterized in that: In step S6, the overlapping situations of the RSU communication coverage on the urban straight road include a single RSU coverage area, a double RSU coverage area, and a triple RSU coverage area. Therefore, the CAV lane changing process has three scenarios: Scenario 1: The CAV lane-changing process is within the coverage of the same RSU; Scenario 2: The CAV lane-changing process is at the intersection of two RSU coverage areas; Scenario 3: The CAV lane-changing process is at the intersection of three RSU coverage areas; Among them, in the first scenario, when the CAV triggers the lane change condition when it enters the RSU coverage area for the first time, the CAV is defined as an HV by the roadside end, and based on the cooperative lane change service strategy guided by the roadside RSU, it relies on the on-board OBU and the roadside RSU to realize the perception and control information interaction, and realizes the cooperative lane change process guided by the roadside; In the second scenario, when the CAV drives to the intersection of the communication coverage areas of the two RSUs and generates the HV lane change intention, two types of situations are considered: 1) The CAV enters the coverage of two RSUs from the coverage of a single RSU: At this time, CAV uploads BSM, SSM, and ISM collaborative driving service information to RSU 1 through OBU, and RCU sends VIR lane change request information to CAV through RSU_1; RSU_1 also transmits collaborative control command information RSC to RSU_2. 2) The cooperative vehicle CAV enters the single RSU coverage area from the dual RSU coverage area: When the CAV is in the overlapping area of ​​dual RSU communication coverage but only within the sensing range of RSU_1, RSU_1 will receive the sensing information SSM and vehicle status information BSM within the received range and transmit it to the roadside cooperative control unit RCU_2 at RSU_2 through optical fiber for algorithm processing; when the CAV is in the overlapping area of ​​dual RSU communication coverage and enters the sensing range of RSU_2, the roadside sensing information SSM and vehicle status information BSM are transmitted from RSU_2 to RCU_2, and the request instruction VIR and control instruction RSC are sent to the CAV through RSU_2; When entering the coverage of a single RSU_2, the communication process of the first scenario is adopted; In the third scenario, the roadside cooperative control unit RCU_2, which is closest to the lane-changing vehicle HV, is used to issue control instructions to the CAV; when just entering the three-RSU coverage area, the vehicle status information BSM, the intention sharing information ISM and the perception information of the previous roadside RSU_1 are all transmitted from RSU_1 to RSU_2, and then transmitted to RCU_2 for roadside calculation; within the three-RSU coverage area, the above information is received by RSU_2 and uploaded to RCU_2 for calculation; when the vehicle is about to exit the overlapping area of ​​the three RSU communication coverage, the roadside information will be transmitted from RSU_2 to RSU_3, and its communication process will be transformed into the second scenario, thereby completing the lane change service.

Images