Vehicle communication method and device, computer readable medium and electronic equipment

Abstract

The embodiment of the invention provides a vehicle communication method and device, a computer readable medium and electronic equipment. The vehicle communication method comprises the following steps: receiving a service capability announcement message broadcasted by a road side unit, wherein the service capability announcement message comprises information of a service support type and a coverage area of the road side unit; generating a service request message, wherein the service request message comprises a service request type and a service request life cycle of the vehicle terminal; if it is determined that a plurality of road side units support the service request type, selecting a target road side unit from the plurality of road side units according to the information of the coverage area, the service request life cycle and the driving state data of the vehicle terminal; and sending the service request message to the target road side unit. According to the technical scheme of the embodiment of the invention, the vehicle terminal can receive the vehicle response message fed back by the road side unit in time after sending the service request message, and the service processing efficiency of the Internet of Vehicles system can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer and communication technology, and in particular, to a vehicle communication method, device, computer-readable medium and electronic device. Background Art

[0002] In the C-V2X (Cellular-Vehicle to Everything) system, the vehicle's OBU (On board Unit) can send request information (such as lane change request, vehicle merging request, etc.) to the RSU (Road Side Unit). After receiving the request information from the vehicle's OBU, the RSU can determine whether to accept the request based on the surrounding vehicle information and surrounding traffic environment information perceived by the roadside, and generate guidance suggestions, and send guidance suggestions to the OBU of the vehicle or the OBU of other related vehicles. Then the vehicle adjusts its driving behavior according to the guidance suggestions and passes safely (such as assisting vehicles to change lanes safely, merge safely, etc.).

[0003] When the vehicle's OBU initiates a request in the overlapping coverage area of ​​multiple RSUs, it may receive signals from multiple RSUs. Therefore, if the OBU does not select a suitable RSU to initiate the request, it may leave the coverage area of ​​the selected RSU without receiving the response information fed back by the RSU, which will cause the request-response process at the application layer to fail and the request needs to be re-initiated, resulting in low system efficiency. Summary of the invention

[0004] The embodiments of the present application provide a vehicle communication method, device, computer-readable medium and electronic device, which can ensure that the vehicle terminal can promptly receive the vehicle response message fed back by the roadside unit after sending the service request message, which is conducive to improving the service processing efficiency of the Internet of Vehicles system.

[0005] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by the practice of the present application.

[0006] In the first aspect, an embodiment of the present application provides a vehicle communication method, including: receiving a service capability announcement message broadcast by a roadside unit, the service capability announcement message including information on the service support type and coverage area of ​​the roadside unit; generating a service request message, the service request message including the service request type and service request lifecycle of a vehicle terminal; if it is determined according to the service support type that multiple roadside units support the service request type, then selecting a target roadside unit from the multiple roadside units according to the coverage area information, the service request lifecycle and the driving status data of the vehicle terminal; and sending the service request message to the target roadside unit.

[0007] In the second aspect, an embodiment of the present application provides a vehicle communication method, including: generating a service capability announcement message, the service capability announcement message including information on the service support type and coverage area of ​​the roadside unit; broadcasting the service capability announcement message, the service capability announcement message being used to enable the vehicle terminal to select a target roadside unit from the multiple roadside units to send a service request message based on the coverage area information, the service request lifecycle of the vehicle terminal and the driving status data of the vehicle terminal when the vehicle terminal determines that there are multiple roadside units supporting the service request type of the vehicle terminal according to the service support type.

[0008] In the third aspect, an embodiment of the present application provides a vehicle communication device, comprising: a receiving unit, configured to receive a service capability announcement message broadcast by a roadside unit, the service capability announcement message containing information on the service support type and coverage area of ​​the roadside unit; a generating unit, configured to generate a service request message, the service request message containing the service request type and service request lifecycle of a vehicle terminal; a selecting unit, configured to select a target roadside unit from the multiple roadside units based on the coverage area information, the service request lifecycle and the driving status data of the vehicle terminal if it is determined according to the service support type that multiple roadside units support the service request type; and a sending unit, configured to send the service request message to the target roadside unit.

[0009] In a fourth aspect, an embodiment of the present application provides a vehicle communication device, comprising: a generation unit, configured to generate a service capability announcement message, the service capability announcement message containing information on the service support type and coverage area of ​​the roadside unit; a broadcast unit, configured to broadcast the service capability announcement message, the service capability announcement message being used to enable the vehicle terminal to select a target roadside unit from the multiple roadside units to send a service request message based on the coverage area information, the service request life cycle of the vehicle terminal and the driving status data of the vehicle terminal when it is determined that there are multiple roadside units supporting the service request type of the vehicle terminal according to the service support type.

[0010] In a fifth aspect, an embodiment of the present application provides a computer-readable medium having a computer program stored thereon, and when the computer program is executed by a processor, the vehicle communication method as described in the above embodiment is implemented.

[0011] In a sixth aspect, an embodiment of the present application provides an electronic device, comprising: one or more processors; a storage device for storing one or more computer programs, wherein when the one or more computer programs are executed by the one or more processors, the electronic device implements the vehicle communication method as described in the above embodiments.

[0012] In a seventh aspect, an embodiment of the present application provides a computer program product, the computer program product comprising a computer program, the computer program being stored in a computer-readable storage medium. A processor of an electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device executes the vehicle communication method provided in the above-mentioned various optional embodiments.

[0013] In the technical solutions provided in some embodiments of the present application, a vehicle terminal (such as an OBU on a vehicle) can receive a service capability announcement message broadcast by a roadside unit that includes the service support type and coverage area information of the roadside unit. If it is determined that multiple roadside units support the service request type of the vehicle terminal according to the service support type of the roadside unit, then a target roadside unit can be selected from multiple roadside units according to the information of the coverage area of ​​the roadside unit, the service request life cycle of the vehicle terminal, and the driving status data of the vehicle terminal, and then the generated service request message is sent to the target roadside unit. It can be seen that in the technical solutions of the embodiments of the present application, the vehicle terminal can select a suitable roadside unit in combination with the information of the coverage area of ​​the roadside unit, the service request life cycle of the vehicle terminal, and the driving status data of the vehicle terminal, that is, select a roadside unit that can receive a vehicle response message for the service request message, thereby ensuring that the vehicle terminal can promptly receive the vehicle response message fed back by the roadside unit after sending the service request message, which is conducive to improving the service processing efficiency of the Internet of Vehicles system.

[0014] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A schematic diagram of the architecture of a C-V2X system is shown;

[0016] Figure 2 A schematic diagram showing the coverage areas of multiple roadside units of an example is shown;

[0017] Figure 3 A schematic diagram showing the coverage areas of multiple roadside units of an example is shown;

[0018] Figure 4 A schematic diagram showing an exemplary system architecture to which the technical solution of the embodiments of the present application can be applied;

[0019] Figure 5 A flow chart of a vehicle communication method according to an embodiment of the present application is shown;

[0020] Figure 6 A flowchart of selecting a target roadside unit according to an embodiment of the present application is shown;

[0021] Figure 7 A flow chart of a vehicle communication method according to an embodiment of the present application is shown;

[0022] Figure 8 A schematic diagram showing various points of a coverage area of ​​a roadside unit according to an embodiment of the present application is shown;

[0023] Fig. 9 A block diagram of a vehicle communication device according to an embodiment of the present application is shown;

[0024] Fig.10 A block diagram of a vehicle communication device according to an embodiment of the present application is shown;

[0025] Fig.11 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0026] The exemplary embodiments are now described in a more comprehensive manner with reference to the accompanying drawings. However, the exemplary embodiments can be implemented in various forms and should not be understood as being limited to these examples; on the contrary, the purpose of providing these embodiments is to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0027] In addition, the features, structures or characteristics described in the present application may be combined in one or more embodiments in any suitable manner. In the following description, there are many specific details so that the embodiments of the present application can be fully understood. However, those skilled in the art will appreciate that when implementing the technical scheme of the present application, all the detailed features in the embodiments may not be needed, one or more specific details may be omitted, or other methods, elements, devices, steps, etc. may be adopted.

[0028] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0029] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0030] It should be noted that the "multiple" mentioned in this article refers to two or more. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects before and after are in an "or" relationship.

[0031] It is understandable that this application can display a prompt interface or pop-up window before collecting relevant data (such as driving status data of vehicle terminals, etc.) and during the process of collecting relevant data. The prompt interface or pop-up window is used to prompt the user that its relevant data is currently being collected, so that this application only starts to execute the steps of obtaining user-related data after obtaining the user's confirmation operation on the prompt interface or pop-up window, otherwise (that is, when the user's confirmation operation on the prompt interface or pop-up window is not obtained), the relevant steps of obtaining user-related data are terminated, that is, the user's relevant data is not obtained. In other words, all data collected by this application are collected with the user's consent and authorization, and the collection, use and processing of relevant user data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0032] like Figure 1As shown in the figure, in the C-V2X system, road-related data can be collected based on the roadside perception unit (such as cameras, millimeter-wave radars, laser radars, etc. installed on the roadside), and then sent to the roadside MEC (Mobile Edge Computing) server. The roadside MEC server can perceive the traffic participants on the road (including motor vehicles, non-motor vehicles, pedestrians, etc.) through fusion computing, and then send the perceived traffic participant information to the C-V2X RSU at a certain frequency (for example: 10Hz). The C-V2X RSU then broadcasts the perceived traffic participant information to the outside through the RSM (Roadside Safety Message) message at a certain frequency. The C-V2X OBU receives the roadside perception information broadcast by the RSU, performs local calculations to see whether the surrounding vehicles pose a threat to it, and then warns the driver of safety risks. The application layer messages between the C-V2X RSU and the C-V2X OBU include not only RSM messages, but also RSI (Road Side Information), MAP (Map Message), SPAT (Signal Phase And Timing), etc.

[0033] At the same time, the C-V2X OBU can send VIR (Vehicle Intention And Request) messages to the C-V2X RSU, such as lane change requests, vehicle merging requests, etc. After receiving the request information from the C-V2X OBU, the C-V2X RSU can determine whether to accept the request based on the surrounding vehicle information and surrounding traffic environment information perceived by the roadside, and generate guidance suggestions, and send guidance suggestions to the C-V2X OBU or the OBU of other related vehicles. Then the vehicle adjusts its driving behavior according to the guidance suggestions and passes safely (such as assisting vehicles to change lanes safely, merge safely, etc.).

[0034] Optionally, the C-V2X RSU and the C-V2X OBU can communicate through the PC5 interface, or through the communication interface (i.e., Uu interface) of a mobile cellular network (such as an LTE network, a 5G network, etc.).

[0035] It should be noted that PC5 interface communication is based on device-to-device (D2D) proximity communication services. The PC5 interface uses the dedicated frequency band for the Internet of Vehicles to achieve direct communication between vehicles, vehicles, roads, and vehicles and people. It has low latency and supports high mobile speeds, but requires good resource allocation and congestion control algorithms. In environments without cellular network coverage, neighboring devices can communicate directly. Uu interface communication is the interface between user equipment and base stations. It uses cellular network frequency bands and transmits information to another node through the V2X server, which can achieve reliable communication over long distances and a larger range. In addition, Figure 1 In the system architecture shown, the roadside MEC can be connected to the cloud control platform, and then the cloud control platform can obtain the information perceived by each roadside MEC, and then display it through a real-time large screen or perform other analysis and calculations.

[0036] Generally speaking, the coverage radius of an RSU is about 400 meters. When providing full network coverage, different RSUs may overlap. Figure 2 As shown in Figure 1, the coverage area of ​​RSU2 overlaps with the coverage areas of RSU1, RSU3, and RSU4. For large overpass scenarios, since there are multiple layers of roads, it is possible to use multiple RSUs to cover different layers of roads. The overlapping area may be larger than Figure 2 More serious.

[0037] In a specific scenario, when the OBU of a vehicle initiates a request in the overlapping coverage area of ​​multiple RSUs, it may receive signals from multiple RSUs. Figure 1 As shown in the figure, the OBU has its own supporting roadside MEC and roadside sensing unit) and lacks the necessary coordination mechanism, so it is impossible for the OBU to initiate a request to one of the RSUs and get a response from another RSU. Therefore, if the OBU does not select a suitable RSU to initiate a request, it may leave the coverage area of ​​the selected RSU before receiving the response information fed back by the RSU, which will cause the request-response process of the application layer to fail and the request needs to be re-initiated, resulting in low efficiency of the system. For example, Figure 3 In the scenario shown, there is an overlapping area among the coverage areas of RSU1, RSU2 and RSU3, and the vehicle terminal 301 is in the overlapping area. If the vehicle terminal 301 is traveling in the direction of RSU2, then after initiating a service request to RSU1 or RSU3, it may have left the coverage area of ​​RSU1 or RSU3 without receiving a response message from RSU1 or RSU3, resulting in the failure of the request-response process at the application layer. Then the vehicle 301 needs to re-initiate the service request.

[0038] In view of the above problems, the embodiments of the present application propose a new vehicle communication solution. Specifically, Figure 4 As shown, an example is given in which there are three roadside units (i.e., roadside unit 401, roadside unit 402, and roadside unit 403) near vehicle terminal 404. Each roadside unit can broadcast a service capability announcement message (Service Announcement Message, referred to as SAM), which contains information about the service support type and coverage area of ​​the roadside unit. When the vehicle terminal 404 needs to send a service request message, it can receive the service capability announcement message broadcasted by each roadside unit at its location, and then determine whether there is a roadside unit that supports the service request type of the vehicle terminal 404 based on the service support type of each roadside unit. If it is determined that there is a roadside unit that supports the service request type of the vehicle terminal 404, then the service request message can be directly sent to this roadside unit.

[0039] If it is determined that there are multiple roadside units that support the service request type of the vehicle terminal 404, then the target roadside unit can be selected from the multiple roadside units based on the information of the coverage area of ​​each roadside unit, the service request life cycle of the vehicle terminal 404, and the driving status data of the vehicle terminal 404. For example, the predicted position of the vehicle terminal 404 after the service request life cycle ends can be calculated based on the driving status data of the vehicle terminal 404, and then the roadside unit whose coverage area includes the predicted position can be selected from the multiple roadside units based on the predicted position. For example, if the predicted position of the vehicle terminal after the service request life cycle ends is as shown in 404' in the figure, then the roadside unit 402 can be selected, and then the vehicle terminal 404 can send a service request message to the roadside unit 402, so that the vehicle terminal 404 can subsequently receive the vehicle response message fed back by the roadside unit 402.

[0040] It can be seen that the technical solution of the embodiment of the present application can ensure that the vehicle terminal can promptly receive the vehicle response message fed back by the roadside unit after sending the service request message, which is conducive to improving the service processing efficiency of the Internet of Vehicles system.

[0041] It should be noted that the vehicle terminal in the embodiment of the present application may specifically refer to an OBU installed on the vehicle, or it may be a smart phone with vehicle-mounted functions, a smart speaker, a speaker with a screen, a smart watch, etc., but is not limited to this.

[0042] The implementation details of the technical solution of the embodiment of the present application are described in detail below:

[0043] Figure 5A flow chart of a vehicle communication method according to an embodiment of the present application is shown. The vehicle communication method can be executed by a vehicle terminal, such as an on-board unit installed in a vehicle. Figure 5 As shown, the vehicle communication method at least includes steps S510 to S540, which are described in detail as follows:

[0044] In step S510, a service capability announcement message broadcast by a roadside unit is received, wherein the service capability announcement message includes information on the service support type and coverage area of ​​the roadside unit.

[0045] In an embodiment of the present application, in order to facilitate the vehicle terminal to select a suitable roadside unit when sending a service request message, so as to promptly receive the vehicle response message fed back by the roadside unit, the roadside unit can add coverage area information when broadcasting a service capability announcement message (SAM). This can facilitate the vehicle terminal to select a suitable roadside unit to send vehicle communication messages based on the coverage area of ​​the roadside unit.

[0046] It should be noted that the coverage area of ​​the roadside unit (i.e., CoverageRegion) refers to the effective communication range of the roadside unit, that is, when the vehicle terminal is within the coverage area, it can communicate with the roadside unit. Specifically, the coverage area can be obtained by measuring the signal indicators of the roadside unit. For example, one of the following signal indicators can be used to determine the coverage area of ​​the roadside unit: RSRP (Reference Signal Receiving Power), RSSI (Received Signal Strength Indication), SNR (Signal Noise Ratio), SINR (Signal to Interference plus Noise Ratio), PRR (Packet Reception Ratio). Taking the selection of RSRP as an example, the RSRP value of -110dBm (the value is only an example) can be used as the boundary of the coverage area of ​​the roadside unit. If the RSRP value at a certain position is greater than -110dBm, it can be considered that the roadside unit has achieved effective coverage at that position.

[0047] Optionally, the service support type of the roadside unit can be defined through the "IntentCooperation" field in the SAM information, which can specifically include supported vehicle-to-vehicle cooperation services and vehicle-to-road cooperation services.

[0048] In some optional embodiments, when the vehicle terminal needs to send a service request message, it can obtain a service capability announcement message that the vehicle terminal can receive at the current location. This can ensure that the subsequently selected target roadside unit can also receive the service capability announcement message sent by the vehicle terminal.

[0049] In step S520, a service request message is generated, and the service request message includes the service request type and service request life cycle of the vehicle terminal.

[0050] In some optional embodiments, the service request type of the vehicle terminal may be a lane change request, a lane merge request, a request to pass through an intersection without a signal light, a request to pass through an intersection with a signal light, etc. The service request lifecycle refers to the time length from when the vehicle terminal expects to send a service request message to when it obtains a vehicle response message fed back by the roadside unit.

[0051] In step S530, if it is determined according to the service support type that multiple roadside units support the service request type, a target roadside unit is selected from the multiple roadside units according to the coverage area information, the service request life cycle and the driving status data of the vehicle terminal.

[0052] In some optional embodiments, if the service request type of the vehicle terminal is a subset of the service support type of the roadside unit, it means that the roadside unit supports the service request type of the vehicle terminal. Optionally, if it is determined that only one roadside unit supports the service request type based on the service support type of the roadside unit and the service request type of the vehicle terminal, then this roadside unit can be used as the target roadside unit.

[0053] In some optional embodiments, the process of selecting a target roadside unit from multiple roadside units based on coverage area information, service request lifecycle, and driving status data of a vehicle terminal may be to predict the coverage area that the vehicle will enter based on the driving status data of the vehicle terminal and the service request lifecycle, and then select the roadside unit based on the coverage area that the vehicle will enter.

[0054] In some optional embodiments, such as Figure 6 As shown, selecting a target roadside unit from multiple roadside units according to the coverage area information, the service request life cycle and the driving status data of the vehicle terminal may include S610 to S630, which are described in detail as follows:

[0055] In S610, the predicted position of the vehicle terminal after the service request life cycle ends is calculated based on the driving status data of the vehicle terminal.

[0056] In some optional embodiments, the driving status data of the vehicle terminal may include driving speed and path planning information, and the path planning information is used to indicate the planned path of the vehicle terminal, that is, the vehicle terminal will travel along the planned path. In this case, the position of the vehicle terminal after traveling along the planned path for a period of time corresponding to the service request life cycle can be calculated based on the driving speed of the vehicle terminal, and the position is used as the predicted position of the vehicle terminal.

[0057] Optionally, when calculating the predicted position of the vehicle terminal after the service request life cycle ends based on the driving status data of the vehicle terminal, the MAP message (i.e., map message) broadcast by the roadside unit can also be referenced to more accurately determine the predicted position of the vehicle terminal. Among them, the MAP message is a V2X MAP message with a unique format, which is inconsistent with the so-called standard map and high-precision map. Generally speaking, the Internet of Vehicles platform can filter out map data within a certain distance range based on the vehicle terminal position, speed, heading and other information in the BSM (Basic Safety Message) message or L-BSM (Light-BSM) message, and assemble these data into a MAP message and send it to the vehicle terminal.

[0058] Optionally, when calculating the predicted position of the vehicle terminal after the service request life cycle ends based on the driving status data of the vehicle terminal, the SPAT (Signal Phase And Timing) message broadcast by the roadside unit can also be referenced on the basis of the MAP message broadcast by the roadside unit. This is because for the SPAT message mainly used in traffic light scenarios, the Internet of Vehicles platform can filter the traffic light data within a certain distance range based on the terminal position, speed, heading and other information in the BSM message or L-BSM message, and assemble the traffic light data into a SPAT message and send it to the vehicle terminal, so that the vehicle terminal can more accurately determine the predicted position of the vehicle terminal based on the SPAT message and the MAP message.

[0059] In S620, based on the information of the coverage area of ​​the roadside unit and the predicted position of the vehicle terminal, a candidate roadside unit whose coverage area includes the predicted position is selected from a plurality of roadside units.

[0060] In some optional embodiments, the candidate roadside unit whose coverage area includes the predicted position of the vehicle terminal may be one or more. Since the coverage area of ​​the candidate roadside unit includes the predicted position of the vehicle terminal, the vehicle terminal can communicate with the candidate roadside units, and then can select a roadside unit from the candidate roadside units to send a service request message, thereby ensuring that the vehicle terminal can receive a vehicle response message for the service request message.

[0061] In S630 , a target roadside unit is selected from the candidate roadside units.

[0062] In some optional embodiments, if there is only one candidate roadside unit, the determined candidate roadside unit can be used as the target roadside unit. If there are multiple candidate roadside units, a set of roadside units whose perception areas include the predicted position can be selected from the multiple candidate roadside units based on the predicted position and the perception areas of the multiple candidate roadside units, and the target roadside unit can be selected from the set of roadside units.

[0063] It should be noted that the perception area is detectedRegion, which is the area that the roadside unit can perceive through the roadside perception unit (such as cameras, radars and other roadside perception devices). Generally speaking, for a roadside unit, the size of the perception area is smaller than the size of the coverage area, that is, the perception area is a subset of the coverage area.

[0064] In some optional embodiments, if the roadside unit set selected from the multiple candidate roadside units according to the predicted position of the vehicle terminal and the sensing areas of the multiple candidate roadside units contains only one roadside unit, then the roadside unit in the roadside unit set can be directly used as the target roadside unit. If the roadside unit set contains at least two roadside units, then a roadside unit can be selected from the at least two roadside units in the roadside unit set in descending order of priority as the target roadside unit.

[0065] Optionally, the priority of the roadside unit may be related to the perception area. The larger the perception area, the higher the priority of the roadside unit, that is, the priority of the roadside unit is positively correlated with the size of the perception area of ​​the roadside unit. Of course, the priority of the roadside unit may also be related to the communication quality. The better the communication quality of the roadside unit, the higher the priority of the roadside unit, that is, the priority of the roadside unit is positively correlated with the communication quality of the roadside unit. In addition, the priority of the roadside unit may also be related to the load. The smaller the load of the roadside unit, the higher the priority of the roadside unit, that is, the priority of the roadside unit is inversely correlated with the load size.

[0066] Continue to refer to Figure 5 As shown, in step S540, the service request message is sent to the target roadside unit.

[0067] In some optional embodiments, since the target roadside unit is selected by the vehicle terminal according to the information of the coverage area of ​​the roadside unit, the service request life cycle of the vehicle terminal and the driving status data of the vehicle terminal, the vehicle terminal can receive the vehicle response message fed back by the target roadside unit after sending the service request message to the target roadside unit. It can be seen that the technical solution of the embodiment of the present application can ensure that the vehicle terminal can timely receive the vehicle response message fed back by the roadside unit after sending the service request message, solve the problem in the related technology that the vehicle response message may not be received and the service request needs to be re-initiated, which is conducive to improving the service processing efficiency of the Internet of Vehicles system.

[0068] Figure 7 A flow chart of a vehicle communication method according to an embodiment of the present application is shown, and the vehicle communication method can be executed by a roadside unit. Figure 7 As shown, the vehicle communication method at least includes steps S710 to S720, which are described in detail as follows:

[0069] In step S710, a service capability announcement message is generated, wherein the service capability announcement message includes information on the service support type and coverage area of ​​the roadside unit.

[0070] In some optional embodiments, before generating a service capability announcement message, the roadside unit may receive coverage area information sent by the control platform. The coverage area information includes multiple coordinate points for describing the coverage area. The multiple coordinate points are points for representing the boundaries of the coverage area determined by measuring the signal indicators of the roadside unit.

[0071] Optionally, one of the following signal indicators can be measured to determine the coverage area of ​​the roadside unit: RSRP, RSSI, SNR, SINR, PRR. Taking RSRP as an example, the RSRP value of -110dBm (the value is only an example) can be used as the boundary of the coverage area of ​​the roadside unit. If the RSRP value at a certain location is greater than -110dBm, it can be considered that the roadside unit has achieved effective coverage at that location. In order to avoid selecting too many coordinate points and causing the amount of data to be transmitted to be too large, several typical points can be selected to describe the coverage area. For example, one or more coordinate points can be selected in each direction on the plane where the coverage area is located.

[0072] In some optional embodiments, the control platform may periodically detect the coverage area of ​​the roadside unit, and then send the detected coverage area information to the roadside unit for broadcasting. That is, the roadside unit may receive the coverage area information periodically sent by the control platform.

[0073] In step S720, a service capability announcement message is broadcast. The service capability announcement message is used to enable the vehicle terminal to select a target roadside unit from multiple roadside units to send a service request message based on coverage area information, the service request lifecycle of the vehicle terminal and the driving status data of the vehicle terminal when the vehicle terminal determines that there are multiple roadside units supporting the service request type of the vehicle terminal according to the service support type.

[0074] In some optional embodiments, the vehicle terminal determines the roadside unit that supports the service request type, and the process of selecting the target roadside unit based on the coverage area information of the roadside unit, the service request lifecycle of the vehicle terminal and the driving status data of the vehicle terminal can refer to the technical solutions of the aforementioned embodiments and will not be repeated here.

[0075] In summary, the technical solution of the embodiment of the present application is mainly that the RSU broadcasts its coverage area, and then the vehicle terminal (such as OBU) calculates the vehicle's position at the end of the future "V2X service request life cycle" based on the vehicle's driving speed, path planning, MAP information broadcast by the RSU, etc., and selects a suitable RSU to initiate a V2X service request message based on the position. The implementation details of the technical solution of the embodiment of the present application are further elaborated below:

[0076] In some optional embodiments, the coverage area of ​​the RSU can be obtained by receiving end testing, such as offline testing through a dedicated network optimization tool, which can test one or more of the average RSRP, RSSI, SNR, SINR, and PRR of each point in the RSU coverage area. After the test is completed, the V2X network operator can select indicators and corresponding indicator values ​​for determining the RSU coverage area, and then determine the coverage area of ​​each RSU, ensuring that the coverage area of ​​the RSU is coherent and overlapped on the road. Taking the selection of RSRP as an example, the RSRP value of -110dBm (the value is only an example) can be used as the boundary of the RSU coverage area. If the RSRP value at a certain location is greater than -110dBm, it can be considered that the RSU has achieved effective coverage at that location. After determining the coverage area of ​​each RSU, the cloud control platform can inform each RSU of the coverage area of ​​each RSU, and the RSU will broadcast it.

[0077] Optionally, the representation method of the sensed region (detectedRegion) in SAM can be referred to, and the coverage area (ie CoverageRegion) of the RSU can be described by a polygon, for example, a polygon with at least four vertices can be used to describe it, and each vertex is represented by [longitude, latitude].

[0078] The network optimization tool may test many points for each RSU. If the positions of the points obtained by the test are directly broadcast, it may cause the RSU broadcast resource overhead to be large. Figure 8 In the example shown, there are 20 points with RSRP of -110dBm in the RSU coverage area. If these 20 points are directly broadcast as the RSU coverage area, the [longitude, latitude] of the 20 points needs to be broadcast to represent the RSU coverage area. In actual applications, several typical points can be selected to approximately represent the RSU coverage area and informed to each RSU, which will broadcast it. For example, you can select Figure 8 Point 801, point 802, point 803, point 804 and point 805 are shown in FIG.

[0079] In some optional embodiments, the V2X network operator needs to continuously maintain the coverage quality of the RSU, so it is necessary to regularly test the coverage of each RSU using a network optimization tool. The cloud control platform can update the coverage area "CoverageRegion" of each RSU according to a certain period.

[0080] In some optional embodiments, when broadcasting the coverage area, the RSU may add the coverage area "CoverageRegion" in the service capability announcement message (ie, SAM) to broadcast the coverage area through the service capability announcement message.

[0081] Specifically, the service capability announcement message (SAM) is used to transmit information such as the service capabilities currently supported by the vehicle or roadside equipment. The CoverageRegion field can be added to the ManeuverCooperation field in the SAM, and the field can be set as an optional field. Optionally, the definition of the ManeuverCooperation field can be as follows:

[0082] ManeuverCooperation::=SEQUENCE{

[0083] equipmentType EquipmentType,

[0084] detectedRegion DetectedRegion OPTIONAL,

[0085] coverageRegion CoverageRegion OPTIONAL,

[0086] intCooperation IntentCooperation

[0087] }

[0088] It can be seen that in the embodiment of the present application, the ManeuverCooperation field includes an equipment type (EquipmentType) field, an optional detection region (DetectedRegion) field, an optional coverage region (CoverageRegion) field, and an IntentCooperation field for defining the supported service types.

[0089] Based on the above scheme, in one embodiment of the present application, when the OBU needs to send a service request message, if the message to be sent is not a V2X service request message, but a BSM message, then it can be sent directly.

[0090] If the OBU sends a V2X service request message, the RSU selection module can be called (the RSU selection module can be a hardware or software module integrated on the OBU), and the planned V2X service request type and V2X service request lifecycle are sent to the RSU selection module. Optionally, the V2X service request type may include: lane change request, merging request, non-signalized intersection pass request, signalized intersection pass request, etc. The V2X service request lifecycle refers to the time from when the OBU expects to send the V2X service request message to when the RSU feedback response message is obtained. This time can be carried when the OBU sends the V2X service request message.

[0091] The RSU selection module analyzes the RSU service capability announcement message (SAM) that can be received at present. If it can only receive the SAM message of one RSU and the RSU supports the service request type that the OBU wants to send, the ID of this RSU will be fed back to the OBU information sending module (the OBU information sending module can be a hardware or software module integrated on the OBU). That is, if it can only receive the SAM message of one RSU and the RSU supports the service request type that the OBU wants to send, the OBU information sending module will send a V2X service request message to this RSU.

[0092] If the RSU selection module can receive SAM messages from multiple RSUs, it extracts the service support type (i.e., the information in the IntentCooperation field) in each RSU SAM message, and filters out the RSUs that support the service request type that the OBU wishes to send; if there is only one RSU obtained after filtering according to the service support type of the RSU, the ID of this RSU is fed back to the OBU information sending module, that is, if there is only one RSU that supports the service request type that the OBU wishes to send, the OBU information sending module sends a V2X service request message to this RSU.

[0093] If there are multiple RSUs after screening according to the service support type of RSU, the coverage area (i.e., "CoverageRegion") in the SAM message of each RSU in these multiple RSUs can be extracted, and then the vehicle's position at the end of the future "V2X service request life cycle" can be calculated through the vehicle's driving speed, path planning, MAP information broadcast by RSU, etc., to check which RSU's coverage area the position is located in. If it is only in the coverage area of ​​one RSU, the ID of the RSU is fed back to the OBU information sending module, that is, if the position is only in the coverage area of ​​one RSU, the OBU information sending module sends a V2X service request message to this RSU.

[0094] If the calculated vehicle position is located in the coverage area of ​​multiple RSUs, the perception areas (i.e. detectedRegion) in these RSU SAM messages are compared again to check in which RSU's perception area the vehicle's position is located at the end of the future "V2X service request lifecycle". If it is only in the perception area of ​​one RSU, the ID of the RSU is fed back to the OBU information sending module. That is, if the position is only in the perception area of ​​one RSU, the OBU information sending module sends a V2X service request message to this RSU.

[0095] If the calculated vehicle position is within the perception area of ​​multiple RSUs, the IDs of these multiple RSUs can be fed back to the OBU information sending module, and the priorities are ranked according to the size of the perception areas of each RSU. The larger the area, the higher the priority, so that the OBU information sending module can select the RSU with a higher priority to send the V2X service request message.

[0096] The technical solution of the above-mentioned embodiment of the present application enables the OBU to select a suitable target RSU when initiating a V2X service request message to the roadside RSU, thereby reducing the problem of request response failure due to failure to select a suitable RSU, and further ensures that the vehicle terminal can promptly receive the vehicle response message fed back by the roadside unit after sending the service request message, which is conducive to improving the service processing efficiency of the Internet of Vehicles system.

[0097] The following describes an apparatus embodiment of the present application, which can be used to execute the vehicle communication method in the above-mentioned embodiment of the present application. For details not disclosed in the apparatus embodiment of the present application, please refer to the above-mentioned embodiment of the vehicle communication method of the present application.

[0098] Fig. 9 A block diagram of a vehicle communication device according to an embodiment of the present application is shown, where the vehicle communication device is applied to a vehicle terminal.

[0099] Reference Fig. 9 As shown, a vehicle communication device 900 according to an embodiment of the present application includes: a receiving unit 902 , a generating unit 904 , a selecting unit 906 and a sending unit 908 .

[0100] Among them, the receiving unit 902 is configured to receive a service capability announcement message broadcast by a roadside unit, wherein the service capability announcement message includes information on the service support type and coverage area of ​​the roadside unit; the generating unit 904 is configured to generate a service request message, wherein the service request message includes the service request type and service request lifecycle of the vehicle terminal; the selecting unit 906 is configured to, if it is determined according to the service support type that multiple roadside units support the service request type, select a target roadside unit from the multiple roadside units according to the coverage area information, the service request lifecycle and the driving status data of the vehicle terminal; the sending unit 908 is configured to send the service request message to the target roadside unit.

[0101] In some embodiments of the present application, based on the aforementioned scheme, the selection unit 906 is configured to: calculate the predicted position of the vehicle terminal after the end of the service request life cycle according to the driving status data of the vehicle terminal; select a candidate roadside unit whose coverage area includes the predicted position from the multiple roadside units according to the information of the coverage area and the predicted position; and select the target roadside unit from the candidate roadside units.

[0102] In some embodiments of the present application, based on the aforementioned scheme, the driving status data includes driving speed and path planning information; the selection unit 906 calculates the predicted position of the vehicle terminal after the end of the service request life cycle according to the driving status data of the vehicle terminal, including: calculating the position of the vehicle terminal after traveling along the planned path corresponding to the path planning information according to the driving speed for a period of time corresponding to the service request life cycle, as the predicted position.

[0103] In some embodiments of the present application, based on the aforementioned scheme, the process of the selection unit 906 selecting the target roadside unit from the candidate roadside units includes: if there is one candidate roadside unit, the one candidate roadside unit is used as the target roadside unit; if there are multiple candidate roadside units, based on the predicted position and the perception areas of the multiple candidate roadside units, a set of roadside units whose perception areas include the predicted position are selected from the multiple candidate roadside units, and the target roadside unit is selected from the roadside unit set.

[0104] In some embodiments of the present application, based on the aforementioned scheme, the process of the selection unit 906 selecting the target roadside unit from the roadside unit set includes: if the roadside unit set contains one roadside unit, then one of the roadside units in the roadside unit set is used as the target roadside unit; if the roadside unit set contains at least two roadside units, then the target roadside unit is selected from the at least two roadside units in descending order of priority.

[0105] In some embodiments of the present application, based on the aforementioned solution, the priority of the roadside unit is positively correlated with the size of the perception area of ​​the roadside unit.

[0106] In some embodiments of the present application, based on the aforementioned scheme, the selection unit 906 is further configured as: if it is determined according to the service support type and the service request type that there is a roadside unit that supports the service request type, then the roadside unit that supports the service request type will be used as the target roadside unit.

[0107] In some embodiments of the present application, based on the aforementioned solution, the receiving unit 902 is configured to: when it is necessary to send the service request message, obtain a service capability announcement message that can be received by the vehicle terminal at the current location.

[0108] Fig.10 A block diagram of a vehicle communication device according to an embodiment of the present application is shown, where the vehicle communication device is applied to a roadside unit.

[0109] Reference Fig.10 As shown, the vehicle communication device 1000 according to an embodiment of the present application includes: a generating unit 1002 and a broadcasting unit 1004 .

[0110] Among them, the generation unit 1002 is configured to generate a business capability announcement message, which includes information on the business support type and coverage area of ​​the roadside unit; the broadcast unit 1004 is configured to broadcast the business capability announcement message, which is used to enable the vehicle terminal to select a target roadside unit from the multiple roadside units to send a business request message based on the coverage area information, the business request life cycle of the vehicle terminal and the driving status data of the vehicle terminal when it is determined that there are multiple roadside units supporting the business request type of the vehicle terminal according to the business support type.

[0111] In some embodiments of the present application, based on the aforementioned scheme, the vehicle communication device 1000 also includes: a receiving unit, configured to receive the coverage area information sent by the control platform before generating a service capability announcement message, the coverage area information including a plurality of coordinate points for describing the coverage area, and the plurality of coordinate points are points for representing the boundary of the coverage area determined by measuring the signal indicators of the roadside unit.

[0112] In some embodiments of the present application, based on the aforementioned scheme, the receiving unit is configured to: receive the information of the coverage area periodically sent by the control platform, and the information of the coverage area periodically sent by the control platform is sent after the control platform periodically detects the coverage area.

[0113] Fig.11 A schematic diagram of the structure of a computer system of an electronic device suitable for implementing an embodiment of the present application is shown, and the electronic device may be a vehicle terminal or a roadside unit in the aforementioned embodiment.

[0114] It should be noted that Fig.11 The computer system 1100 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0115] like Fig.11 As shown, the computer system 1100 may include a central processing unit (CPU) 1101, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1102 or the program loaded from the storage part 1108 to the random access memory (RAM) 1103, such as executing the method described in the above embodiment. In the RAM 1103, various programs and data required for system operation are also stored. The CPU 1101, the ROM 1102 and the RAM 1103 are connected to each other through the bus 1104. The input / output (I / O) interface 1105 is also connected to the bus 1104.

[0116] The following components can be connected to the I / O interface 1105: an input section 1106 including a keyboard, a mouse, etc.; an output section 1107 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the I / O interface 1105 as needed. A removable medium 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1110 as needed so that a computer program read therefrom is installed into the storage section 1108 as needed.

[0117] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program is used to perform the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 1109, and / or installed from a removable medium 1111. When the computer program is executed by a central processing unit (CPU) 1101, various functions defined in the system of the present application are executed.

[0118] It should be noted that the computer-readable medium shown in the embodiment of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a computer program, which may be used by an instruction execution system, device or device or used in combination with it. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0119] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and a computer program.

[0120] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0121] As another aspect, the present application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiment; or may exist independently without being assembled into the electronic device. The above computer-readable medium carries one or more computer programs, and when the above one or more computer programs are executed by an electronic device, the electronic device implements the method described in the above embodiment.

[0122] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0123] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the implementation methods of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable an electronic device to execute the method according to the implementation methods of the present application.

[0124] For example, the electronic device may be a vehicle terminal, and the vehicle terminal may execute Figure 5 As another example, the electronic device may be a roadside unit, and the roadside unit may execute Figure 7 The vehicle communication method shown.

[0125] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application.

[0126] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A vehicle communication method, characterized in that: include: Receiving a service capability announcement message broadcast by a roadside unit, wherein the service capability announcement message includes information on a service support type and a coverage area of ​​the roadside unit; Generate a service request message, wherein the service request message includes a service request type and a service request life cycle of the vehicle terminal; If it is determined according to the service support type that multiple roadside units support the service request type, selecting a target roadside unit from the multiple roadside units according to the coverage area information, the service request life cycle and the driving status data of the vehicle terminal; The service request message is sent to the target roadside unit.

2. The vehicle communication method according to claim 1, characterized in that: Selecting a target roadside unit from the plurality of roadside units according to the information of the coverage area, the service request lifecycle, and the driving status data of the vehicle terminal includes: Calculating, based on the driving status data of the vehicle terminal, a predicted position of the vehicle terminal after the life cycle of the service request ends; Selecting, from the plurality of roadside units, a candidate roadside unit whose coverage area includes the predicted location according to the information of the coverage area and the predicted location; The target roadside unit is selected from the candidate roadside units.

3. The vehicle communication method according to claim 2, characterized in that: The driving status data includes driving speed and path planning information; Calculating, according to the driving state data of the vehicle terminal, a predicted position of the vehicle terminal after the life cycle of the service request ends, including: The position of the vehicle terminal after traveling along the planned path corresponding to the path planning information for a time period corresponding to the life cycle of the service request is calculated according to the driving speed as the predicted position.

4. The vehicle communication method according to claim 2, characterized in that: Selecting the target roadside unit from the candidate roadside units includes: If there is a candidate roadside unit, taking the candidate roadside unit as the target roadside unit; If there are multiple candidate roadside units, a set of roadside units whose perception areas include the predicted position is selected from the multiple candidate roadside units based on the predicted position and the perception areas of the multiple candidate roadside units, and the target roadside unit is selected from the set of roadside units.

5. The vehicle communication method according to claim 4, characterized in that: Selecting the target roadside unit from the roadside unit set includes: If the roadside unit set includes a roadside unit, taking a roadside unit in the roadside unit set as the target roadside unit; If the roadside unit set includes at least two roadside units, the target roadside unit is selected from the at least two roadside units in descending order of priority.

6. The vehicle communication method according to claim 5, characterized in that: The priority of the roadside unit is positively correlated with the size of the perception area of ​​the roadside unit.

7. The vehicle communication method according to claim 1, characterized in that: The vehicle communication method further includes: If it is determined according to the service support type and the service request type that there is a roadside unit that supports the service request type, the roadside unit that supports the service request type is used as the target roadside unit.

8. The vehicle communication method according to any one of claims 1 to 7, characterized in that: Receive service capability announcement messages broadcast by roadside units, including: When the service request message needs to be sent, a service capability announcement message that can be received by the vehicle terminal at the current location is obtained.

9. A vehicle communication method, characterized in that: include: Generate a service capability announcement message, wherein the service capability announcement message includes information about the service support type and coverage area of ​​the roadside unit; The service capability announcement message is broadcasted, and the service capability announcement message is used to enable the vehicle terminal to select a target roadside unit from the multiple roadside units to send a service request message based on the coverage area information, the service request life cycle of the vehicle terminal and the driving status data of the vehicle terminal when the vehicle terminal determines that there are multiple roadside units supporting the service request type of the vehicle terminal according to the service support type.

10. The vehicle communication method according to claim 9, characterized in that: Before generating the service capability announcement message, the vehicle communication method further includes: Receive the coverage area information sent by the control platform, the coverage area information includes a plurality of coordinate points for describing the coverage area, the plurality of coordinate points are points for indicating the boundary of the coverage area determined by measuring the signal indicators of the roadside unit.

11. The vehicle communication method according to claim 10, characterized in that: Receiving the information of the coverage area sent by the control platform, including: The information of the coverage area periodically sent by the control platform is received, where the information of the coverage area periodically sent by the control platform is sent after the control platform periodically detects the coverage area.

12. A vehicle communication device, characterized in that: include: A receiving unit configured to receive a service capability announcement message broadcast by a roadside unit, wherein the service capability announcement message includes information on a service support type and a coverage area of ​​the roadside unit; A generating unit configured to generate a service request message, wherein the service request message includes a service request type and a service request life cycle of the vehicle terminal; A selection unit configured to select a target roadside unit from the multiple roadside units according to the coverage area information, the service request life cycle and the driving status data of the vehicle terminal if it is determined that multiple roadside units support the service request type according to the service support type; The sending unit is configured to send the service request message to the target roadside unit.

13. A vehicle communication device, characterized in that: include: A generating unit configured to generate a service capability announcement message, wherein the service capability announcement message includes information on a service support type and a coverage area of ​​the roadside unit; The broadcast unit is configured to broadcast the service capability announcement message, wherein the service capability announcement message is used to enable the vehicle terminal to select a target roadside unit from the multiple roadside units to send a service request message based on the coverage area information, the service request life cycle of the vehicle terminal and the driving status data of the vehicle terminal when the vehicle terminal determines that there are multiple roadside units supporting the service request type of the vehicle terminal according to the service support type.

14. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the vehicle communication method according to any one of claims 1 to 11 is implemented.

15. An electronic device, characterized in that: include: one or more processors; A memory for storing one or more computer programs, which, when executed by the one or more processors, enables the electronic device to implement the vehicle communication method as claimed in any one of claims 1 to 11.

Images