A data transmission method and device, a vehicle and a storage medium

Abstract

The application provides a data transmission method and device, a vehicle and a storage medium, relates to the technical field of data processing, and is used for solving the technical problem that a vehicle cannot ensure the timeliness of transmission of key service data in a weak network environment. The data transmission method is applied to a vehicle, and the method comprises the following steps: in the case that it is detected that the wireless network state of the vehicle is in a weak network state, determining a target vehicle-mounted scene in which the vehicle currently locates; determining a target scheduling strategy matched with the target vehicle-mounted scene from a plurality of preset scheduling strategies according to the target vehicle-mounted scene, wherein the target scheduling strategy is used for indicating a data sending mode of a plurality of sending queues in the target vehicle-mounted scene, and the plurality of sending queues are used for associating data packets to be sent of different service priorities; and performing scheduling and sending on the data packets in the plurality of sending queues according to the target scheduling strategy.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data transmission method, apparatus, vehicle, and storage medium. Background Technology

[0002] Vehicle-to-everything (V2X) communication serves as a crucial link between vehicles and external devices (such as other vehicles, roadside units, and cloud platforms), carrying data interaction for diverse services including safety warnings, collaborative driving, and remote monitoring. However, due to uneven network coverage, vehicles are highly susceptible to weak network environments during operation (such as entering tunnels, remote areas, or signal blind spots), leading to deterioration in communication quality between vehicles and external devices. In such situations, if vehicles still use a first-in-first-out (FIFO) scheduling rule to send data packets, it will result in increased transmission delays for some critical business data, potentially causing serious traffic safety problems. Summary of the Invention

[0003] This application provides a data transmission method, apparatus, vehicle, and storage medium to solve the technical problem that vehicles cannot ensure the timeliness of transmission of critical business data in weak network environments.

[0004] In a first aspect, embodiments of this application provide a data transmission method applied to a vehicle. The method includes: when the wireless network status of the vehicle is detected to be in a weak network state, determining the target vehicle-mounted scenario in which the vehicle is currently located; determining a target scheduling strategy matching the target vehicle-mounted scenario from a plurality of preset scheduling strategies, wherein the target scheduling strategy is used to indicate the data transmission method of a plurality of transmission queues in the target vehicle-mounted scenario, and the plurality of transmission queues are used to associate data packets to be transmitted with different service priorities; and scheduling and transmitting the data packets in the plurality of transmission queues according to the target scheduling strategy.

[0005] In this embodiment, when the vehicle is in a weak network state, a target scheduling strategy matching the target vehicle scenario is dynamically selected based on the current target vehicle scenario. Since each sending queue corresponds to a service priority, and the target scheduling strategy indicates the data sending method matching the target vehicle scenario, data packets in multiple sending queues are sent based on the target scheduling strategy. This can effectively ensure that critical business data in the target vehicle scenario is processed first when sending data, thereby ensuring the timeliness of transmission of critical business data in the target vehicle scenario in a weak network environment.

[0006] In one possible implementation, when the target vehicle scenario is a non-assisted driving scenario, the step of scheduling and sending data packets in the plurality of sending queues according to the target scheduling strategy includes: obtaining the target bandwidth allocation ratio corresponding to each of the plurality of sending queues; determining the actual available bandwidth corresponding to each sending queue based on the target bandwidth allocation ratio corresponding to each sending queue and the total available bandwidth of the vehicle in the current wireless network state; and controlling the sending rate of data packets in the plurality of sending queues based on the actual available bandwidth corresponding to each sending queue.

[0007] In this implementation, when the target vehicle scenario is non-assisted driving, since the vehicle is driven by the user, a certain proportion of bandwidth is allocated to other non-safety services, provided that the target scheduling strategy can prioritize the timeliness of data transmission for driving safety-related services. This prevents single-service data from monopolizing network resources, ensures the basic functional availability of other non-safety services, and improves the user experience.

[0008] In one possible implementation, obtaining the target bandwidth allocation ratio corresponding to each of the plurality of transmission queues includes: identifying whether the vehicle is in a driving state; if the vehicle is in a driving state, determining a first bandwidth allocation ratio corresponding to each transmission queue; if the vehicle is not in a driving state, determining a second bandwidth allocation ratio corresponding to each transmission queue; wherein, the first bandwidth allocation ratio corresponding to the target transmission queue is higher than the second bandwidth allocation ratio corresponding to the target transmission queue, and the target transmission queue is used to store data packets for driving safety services.

[0009] In this implementation, in non-auxiliary scenarios, based on the different levels of demand for driving safety services when the vehicle is in driving or not, differentiated bandwidth allocation ratios are configured for driving and non-driving states, achieving on-demand allocation of network resources. This fine-grained bandwidth allocation ratio configuration strategy can effectively maintain the functional availability of non-safety services while ensuring the timeliness of transmission of driving safety service data, thereby improving the overall utilization efficiency of network resources.

[0010] In one possible implementation, obtaining the target bandwidth allocation ratio corresponding to each of the plurality of transmission queues includes: obtaining the vehicle's historical driving data, the historical driving data including the historical bandwidth characteristics of each transmission queue when the vehicle is in different vehicle scenarios under historical weak network conditions; and correcting the initial bandwidth allocation ratio corresponding to each transmission queue based on the historical bandwidth characteristics of each transmission queue when the vehicle is in the non-assisted driving scenario under historical weak network conditions to obtain the target bandwidth allocation ratio corresponding to each transmission queue.

[0011] In this implementation, the initial bandwidth allocation ratio of each transmission queue is corrected based on the historical bandwidth characteristics of each transmission queue in the vehicle's non-assisted driving scenario in historical driving data. The resulting target bandwidth allocation ratio is more in line with actual business needs, reduces the waste of network resources, and improves the utilization rate of network resources.

[0012] In one possible implementation, when the target vehicle scenario is an assisted driving scenario, the step of scheduling and sending data packets in the plurality of sending queues according to the target scheduling strategy includes: sending data packets in the plurality of sending queues in descending order according to the service priorities corresponding to the plurality of sending queues, wherein the priority of the vehicle's driving safety services is the highest service priority.

[0013] In this implementation, in the assisted driving scenario, data in the sending queue with higher service priority is sent first, according to the service priority of the multiple sending queues in descending order. In this way, service data of driving safety-related services are sent first, thereby effectively ensuring the timeliness of transmission of driving safety-related services and thus effectively ensuring driving safety in the assisted driving scenario.

[0014] In one possible implementation, determining a target scheduling strategy matching the target vehicle scenario from a set of preset scheduling strategies based on the target vehicle scenario includes: determining a target driving safety level corresponding to the vehicle based on the target vehicle scenario, wherein the target driving safety level is used to indicate the degree of real-time data interaction requirements of the vehicle for driving safety-related services in the target vehicle scenario; and determining a data scheduling rule that has a mapping relationship with the driving safety level as the target scheduling strategy.

[0015] In this implementation, based on the real-time data interaction requirements of vehicles for driving safety services in different vehicle scenarios, corresponding target scheduling strategies are dynamically matched to allocate network resources on demand under weak network conditions. This ensures the timeliness of transmission of driving safety services in different vehicle scenarios while reducing unnecessary resource waste and effectively improving network resource utilization.

[0016] In one possible implementation, the vehicle includes multiple electronic control units (ECUs) for generating data packets of various service types. Before scheduling and sending the data packets in the multiple sending queues according to the target scheduling strategy, the method further includes: receiving data packets to be sent from a target ECU; identifying the service type corresponding to the data packets to be sent and marking the data packets to be sent with a priority identifier according to the service type; and mapping and storing the data packets to be sent into the corresponding sending queues according to the priority identifier.

[0017] In this implementation, by adding a priority identifier to the data packets to be sent, the vehicle can identify data of different service types by recognizing the priority identifier. Thus, in a weak network environment, the vehicle can prioritize the processing of critical services based on the current target vehicle scenario, thereby ensuring the service quality of critical services in a weak network environment.

[0018] Secondly, embodiments of this application provide a data transmission device applied to a vehicle. The data transmission device includes: a determining module, configured to determine the target vehicle scenario when the vehicle's wireless network is detected to be in a weak network state; and to determine a target scheduling strategy matching the target vehicle scenario from a plurality of preset scheduling strategies, wherein the target scheduling strategy is used to indicate the data transmission method of a plurality of transmission queues in the target vehicle scenario, and each transmission queue is used to associate data packets to be transmitted with different service priorities; and a transmission module, configured to schedule and transmit data packets in the plurality of transmission queues according to the target scheduling strategy.

[0019] Thirdly, embodiments of this application provide a vehicle, including: a memory storing executable program code; a processor coupled to the memory; the processor invokes the executable program code stored in the memory to execute the method as described in the first aspect and any possible implementation.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the methods described in the first aspect and any possible implementation.

[0021] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in the first aspect and any possible implementation.

[0022] The beneficial effects of aspects two through five can be referred to in the same way as the beneficial effects described in aspect one, and will not be repeated here. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This application provides an illustration of an application scenario for a data transmission method. Figure 1 ; Figure 2 This application provides an illustration of an application scenario for a data transmission method. Figure 2 ; Figure 3 A flowchart illustrating a data transmission method provided in this application embodiment. Figure 1 ; Figure 4 A schematic diagram illustrating the correction of the initial bandwidth allocation ratio based on the average bandwidth usage ratio, provided for an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an IP data packet provided in an embodiment of this application; Figure 6 A schematic diagram illustrating the flow of data packets within a vehicle, provided as an embodiment of this application; Figure 7 A flowchart illustrating a data transmission method provided in this application embodiment. Figure 2 ; Figure 8 This is a schematic diagram of the structure of a data transmission device provided in an embodiment of this application; Figure 9 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0026] To facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with essentially the same function and effect. For example, "first instruction" and "second instruction" are used to distinguish different user instructions and do not limit their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0027] It should be noted that, in this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0028] Furthermore, "at least one" refers to one or more, while "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can mean: a, or b, or c, or a and b, or a and c, or b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0029] Furthermore, the terms "comprising" and "having," and any variations thereof, in the embodiments and drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0030] As a key link for communication between vehicles and external devices (such as other vehicles, roadside units, and cloud platforms), the Internet of Vehicles (IoV) carries data interaction for diverse services such as safety warnings, driving collaboration, and remote monitoring.

[0031] Currently, vehicular networks (especially those connecting to external networks via telematics boxes (T-BOX)) typically employ a uniform or simple, fixed priority strategy for transmitting data across all service types (such as vehicle status reporting, over-the-air (OTA) upgrades, audio-visual entertainment, and navigation map updates). This strategy is largely effective when wireless network signal strength is good and bandwidth is sufficient.

[0032] However, when vehicles enter environments with weak network conditions such as tunnels, underground parking garages, and remote mountainous areas, the available uplink and downlink bandwidth on the wireless side (e.g., 4G / 5G) is significantly reduced, even falling below the total bandwidth requirements of all concurrent data services within the vehicle. In such situations, indiscriminate or simple priority strategies cannot effectively guarantee the real-time performance and reliability of high-priority services such as driving safety (e.g., acquiring quasi-base station information for Real-time Kinematic (RTK) positioning technology and receiving remote diagnostic commands) and user experience-critical services (e.g., real-time navigation and voice interaction). Low-priority services (e.g., downloading large OTA packages and caching entertainment content) may occupy limited bandwidth for extended periods, causing high-priority service data packets to be delayed, dropped, or fail to transmit, seriously threatening driving safety or rendering core functions unavailable.

[0033] In addition, some data transmission methods attempt to rely on the Quality of Service (QoS) provided by mobile network operators, but the following problems still exist: (a) Operator QoS usually provides a uniform QoS priority, which is difficult to finely match the various and dynamically changing specific service types in the vehicle and their in-vehicle defined priorities; (b) Operator-side configuration is complex and inflexible, which cannot meet the needs of car manufacturers to quickly define and adjust the in-vehicle service priorities; (c) It is impossible to perceive the specific service concurrency and bandwidth demand pressure in the vehicle; (d) Operators basically set the QoS level for vehicle networking to a fixed value, which requires charging high fees for customized needs of vehicle models.

[0034] It is evident that traditional vehicle-mounted data transmission methods lack an effective mechanism for autonomous and intelligent bandwidth management and data packet scheduling by the in-vehicle telematics box (TBOX) based on fine-grained service priorities defined within the vehicle, thus failing to proactively safeguard critical services under weak network conditions.

[0035] Based on this, this application provides a data transmission method for vehicles. When the vehicle's wireless network is in a weak network state, the method dynamically selects a target scheduling strategy that matches the target vehicle scenario. Since each transmission queue corresponds to a service priority, and the target scheduling strategy indicates the data transmission method that matches the target vehicle scenario, data packets in multiple transmission queues are sent based on the target scheduling strategy. This effectively ensures that critical business data in the target vehicle scenario is processed first during data transmission, thereby guaranteeing the timeliness of transmission of critical business data in the target vehicle scenario in a weak network environment.

[0036] It should be noted that the acquisition, transmission, storage, and use of data in the embodiments of this application all comply with the requirements of relevant national laws and regulations.

[0037] To better understand the data transmission method provided in the embodiments of this application, the application scenarios of the method described in the embodiments of this application are illustrated below.

[0038] Please refer to Figure 1 This is an illustration of an application scenario for a data transmission method provided in this application embodiment. Figure 1 .like Figure 1 As shown in the diagram, the schematic includes a vehicle 110 and an external device 120. The vehicle 110 can wirelessly communicate with the external device 120. Wireless communication may include cellular mobile networks or direct communication. Cellular mobile networks may include fourth-generation mobile communication technology (4G) or fifth-generation mobile communication technology (5G). Direct communication may include cellular vehicle-to-everything (V2X) communication (or vehicular wireless communication based on cellular technology) or Dedicated Short-Range Communications (DSRC).

[0039] External device 120 refers to devices that need to interact with vehicle 110, such as cloud platforms, data centers, other vehicles, roadside units, or pedestrian devices. Cloud platforms include cloud platforms corresponding to vehicle manufacturers, cloud platforms operated by third-party service providers (such as those used to provide map data, infotainment services, real-time traffic information, etc.), etc. The embodiments of this application will not be described in detail here.

[0040] For example, please refer to Figure 2 This is an illustration of an application scenario for a data transmission method provided in this application embodiment. Figure 2 .like Figure 2As shown in the diagram, the schematic includes a first vehicle 210, a first cloud platform 220, a second cloud platform 230, and a second vehicle 240. The first vehicle 210 can wirelessly communicate with the first cloud platform 220 and the second cloud platform 230 via a cellular mobile network. The first vehicle 210 can also wirelessly communicate with the second vehicle 240 via a direct connection.

[0041] It should be noted that the embodiments of this application use the first vehicle 210 to perform data interaction with the first cloud platform 220, the second cloud platform 230 and the second vehicle 240 as an example. However, in actual applications, the number of external devices that have data interaction needs with the vehicle may be more or less, and the embodiments of this application do not limit this.

[0042] Since the first vehicle 210 has data interaction needs with multiple external devices, when the first vehicle 210 is in a weak network environment, the scheduling strategy of the first vehicle 210 can be adjusted accordingly to prioritize the processing of key business data in the target vehicle scenario under limited bandwidth resources, thereby ensuring the timeliness of transmission of key business data in the target vehicle scenario in a weak network environment.

[0043] The following is a detailed description of a data transmission method for vehicles provided by an embodiment of this application.

[0044] Please refer to Figure 3 This is a schematic flowchart illustrating a data transmission method provided in an embodiment of this application. The following description assumes a vehicle performing the steps described below; for example, the vehicle... Figure 1 The vehicle 110 shown, or for example Figure 2 The first vehicle 210 shown.

[0045] S301 determines the target in-vehicle scenario where the vehicle is currently located when the vehicle's wireless network is detected to be in a weak network state.

[0046] In this context, a weak network condition can be understood as a network condition with poor network performance and communication quality. A weak network condition can be identified by monitoring network status parameters of the vehicle's wireless network, including but not limited to: available bandwidth, latency, jitter, and packet loss rate.

[0047] In some implementations, the vehicle can detect whether its wireless network is in a weak network state based on at least one network status parameter of the uplink and downlink. This at least one network status parameter may include, for example, available bandwidth, available bandwidth and packet loss rate, available bandwidth and latency, available bandwidth, latency and jitter, or available bandwidth, latency, jitter and packet loss rate, etc. It should be understood that at least one network status parameter can be any combination of the above-mentioned network status parameters (such as available bandwidth, latency, jitter, and packet loss rate) and other network status parameters not listed in the embodiments of this application (such as signal strength, signal-to-noise ratio, etc.), which will not be listed and described in detail in the embodiments of this application.

[0048] For example, taking at least one network status parameter including available bandwidth, latency, jitter, and packet loss rate as an example, when it is detected that the available bandwidth is less than or equal to a first preset threshold, the latency is greater than or equal to a second preset threshold, the jitter is greater than or equal to a third preset threshold, and the packet loss rate is greater than or equal to a fourth preset threshold, the vehicle's wireless network status is determined to be in a weak network state. Alternatively, when it is detected that at least one (or at least two, etc.) of the four indicators of available bandwidth, latency, jitter, and packet loss rate does not meet their respective preset thresholds, the vehicle's wireless network status is determined to be in a weak network state. The first, second, third, and fourth preset thresholds are all pre-configured in the vehicle and can be set according to actual needs, for example, through experimentation or experience. This embodiment of the application does not limit this.

[0049] The vehicle monitors network status parameters in real time to determine whether its wireless network is in a weak state. If the vehicle's wireless network is in a weak state, the target in-vehicle scenario is identified to determine the appropriate target scheduling strategy. The specific method for determining the target scheduling strategy will be described below. If the vehicle's wireless network is not in a weak state, the vehicle can send data packets according to the original scheduling rules, such as first-in-first-out or predefined priority scheduling strategies, which are not limited in this embodiment.

[0050] The target in-vehicle scenario can be either an assisted driving scenario or a non-assisted driving scenario. An assisted driving scenario can be understood as a scenario where, while the driver is driving, the vehicle uses onboard sensors, cameras, radar, and other devices to perceive the environment in real time, and assists the driver in completing the driving task with the help of algorithms and control systems. A non-assisted driving scenario can be understood as a scenario where the driver is fully responsible for completing the driving task.

[0051] S302, based on the target vehicle scenario, determine the target scheduling strategy that matches the target vehicle scenario from multiple preset scheduling strategies. The target scheduling strategy is used to indicate the data transmission method of multiple transmission queues in the target vehicle scenario. The multiple transmission queues are used to associate data packets with different service priorities.

[0052] Each of the multiple scheduling strategies corresponds to a specific vehicle-mounted scenario; in other words, different vehicle-mounted scenarios require different scheduling strategies. Each scheduling strategy indicates the data transmission method for multiple transmission queues within a single vehicle-mounted scenario. Therefore, the data transmission methods for multiple transmission queues differ across different vehicle-mounted scenarios. The data transmission method may include the order in which data packets are transmitted or the bandwidth allocation ratio.

[0053] Multiple transmission queues are used to store data packets to be sent for various service types. For example, these service types include: vehicle safety services, services prioritizing user experience, services with weak user experience, and services that are imperceptible to the user. Vehicle safety services include V2X (Vehicle to Everything) safety messages, sensor data, remote monitoring services, and safety diagnostics services; services prioritizing user experience include map and navigation services, remote vehicle control services, and basic status reporting services; services with weak user experience include infotainment services; and services that are imperceptible to the user include software updates and non-real-time data uploads.

[0054] Each sending queue stores data packets with a service priority, and one service priority can correspond to one or more service types. For example, taking the service types as driving safety, high user experience, low user experience, and user-unawareness, the corresponding priority order is as follows: Driving safety > High user experience > Low user experience > User-unawareness. It should be noted that this embodiment uses one service type corresponding to one service priority as an example for illustration. However, in practical applications, multiple service types can correspond to one service priority. For example, high user experience and low user experience can be defined as having the same service priority. The specific setting can be determined according to the actual situation, and this embodiment does not limit this.

[0055] It should be noted that the embodiments of this application use four business priorities as examples: driving safety, heavy user experience, weak user experience, and user-unawareness. However, in actual applications, the priorities can be divided into more levels (such as further subdividing the driving safety business) or merged into fewer levels (such as merging the user-unawareness and weak user experience categories) according to actual business needs. The embodiments of this application do not limit this.

[0056] In some implementations, the vehicle can determine its target driving safety level based on the target in-vehicle scenario. The target driving safety level indicates the vehicle's real-time requirement for data interaction related to driving safety in the target in-vehicle scenario.

[0057] For example, a vehicle can identify the real-time data interaction requirements of a target in-vehicle scenario for driving safety-related services based on a pre-trained safety prediction model, in order to determine the target driving safety level of the vehicle. The safety prediction model can be trained based on historical in-vehicle scenarios and their corresponding historical driving data.

[0058] Alternatively, the vehicle can calculate the target driving safety level based on multi-dimensional data from the target in-vehicle scenario and corresponding scoring rules. This multi-dimensional data includes, but is not limited to, vehicle control autonomy, road complexity, traffic density, and weather conditions. By weighting and scoring the multi-dimensional data, a weighted total score is obtained, which can then be used to map the target driving safety level.

[0059] Alternatively, the vehicle can determine the target driving safety level corresponding to the target vehicle scenario based on the pre-defined mapping relationship between various in-vehicle scenarios and multiple scheduling strategies.

[0060] Then, the vehicle can determine the data scheduling rules that are mapped to the target driving safety level, and use them as the target scheduling strategy.

[0061] For example, please refer to Table 1, which shows a mapping relationship between various driving safety levels and multiple scheduling strategies provided in an embodiment of this application.

[0062] Table 1

[0063] As shown in Table 1, when the driving safety level is L1, the corresponding target scheduling strategy is scheduling strategy 1. When the driving safety level is L2, the corresponding target scheduling strategy is scheduling strategy 2. When the driving safety level is L3, the corresponding target scheduling strategy is scheduling strategy 3.

[0064] In this implementation, by identifying the real-time data interaction requirements of vehicles for driving safety services in different in-vehicle scenarios, corresponding target scheduling strategies are dynamically matched to them, and network resources are allocated on demand in weak network conditions. This ensures the timeliness of transmission of driving safety services while reducing unnecessary resource waste and effectively improving network resource utilization.

[0065] S303, according to the target scheduling strategy, schedules and sends data packets in multiple sending queues.

[0066] The vehicle sends data packets to multiple transmission queues according to the data transmission method specified in the target scheduling strategy. The scheduling strategy varies depending on the vehicle scenario, and consequently, the corresponding data transmission method also differs. For example, in a non-assisted driving scenario, the target scheduling strategy is related to the bandwidth allocation ratio; in an assisted driving scenario, the target scheduling strategy is related to the order in which the data packets are sent.

[0067] The following sections will provide a detailed explanation of the data transmission methods in two in-vehicle scenarios: a non-assisted driving scenario and an assisted driving scenario.

[0068] 1. Non-assisted driving scenarios.

[0069] When the target vehicle scenario is a non-assisted driving scenario, the vehicle allocates differentiated bandwidth ratios to each sending queue to enable on-demand transmission of data packets with different service priorities.

[0070] In one possible implementation, the vehicle can obtain the target bandwidth allocation ratio corresponding to each of multiple transmission queues. The target bandwidth allocation ratio may be pre-configured within the vehicle. For example, using the multiple transmission queues shown in Table 2, and taking one transmission queue each for four service priorities—driving safety, heavy user experience, weak user experience, and user-unawareness—as an example, the target bandwidth allocation ratio for each transmission queue is illustrated below.

[0071] Table 2

[0072] As shown in Table 2, the traffic safety category, the user experience-intensive category, the user experience-insensitive category, and the user-unaware category correspond to the transmission queues Q4, Q3, Q2, and Q1, respectively. The target bandwidth allocation ratio for these four transmission queues can be Q4:Q3:Q2:Q1 = 5:3:1:1. This means that the target bandwidth allocation ratio for traffic safety services is 50%, for user experience-intensive services it is 30%, for user experience-insensitive services it is 10%, and for user-unaware services it is 10%.

[0073] After determining the target bandwidth allocation ratio for each transmission queue, the actual available bandwidth for each transmission queue can be determined based on the target bandwidth allocation ratio for each transmission queue and the total available bandwidth of the vehicle in the current wireless network state. For example, continuing with Table 2 above, with the total available bandwidth of the vehicle's current wireless network state being 8 Mbps, according to Q4:Q3:Q2:Q1=5:3:1:1, the actual available bandwidth of Q4 can be calculated as 8 Mbps × 50% = 4.0 Mbps; the actual available bandwidth of Q3 is 8 Mbps × 30% = 2.4 Mbps; the actual available bandwidth of Q2 is 8 Mbps × 10% = 0.8 Mbps; and the actual available bandwidth of Q1 is 8 Mbps × 10% = 0.8 Mbps.

[0074] Finally, the vehicle can control the transmission rate of data packets in multiple transmission queues based on the actual available bandwidth corresponding to each transmission queue. For example, combining the actual available bandwidth corresponding to Q4, Q3, Q2, and Q1 in the example above, the vehicle can stably transmit data packets such as V2X safety messages and sensor data in the Q4 transmission queue at a rate of 4.0 Mbps, transmit data packets such as navigation map updates in the Q3 transmission queue at a rate of 2.4 Mbps, play data packets such as online music in the Q2 transmission queue at a rate of 0.8 Mbps, and transmit data packets such as log data in the Q1 transmission queue at a rate of 0.8 Mbps.

[0075] It should be noted that in this embodiment of the application, the total available bandwidth of the vehicle's current wireless network status is 8 Mbps and Q4:Q3:Q2:Q1=5:3:1:1 is used as an example for illustration. However, the total available bandwidth of the vehicle can also be other values, which need to be determined according to the actual environment of the vehicle. The target bandwidth allocation ratio of each transmission queue can also be set according to experience or experimental data. This embodiment of the application does not limit this.

[0076] In another possible implementation, in non-assisted driving scenarios, the real-time requirements for data interaction of driving safety services vary depending on the driving state. Therefore, the target bandwidth allocation ratio of each sending queue can be different in different driving states.

[0077] In this implementation, the vehicle can identify whether it is in a driving state. When the vehicle is in a driving state, a first bandwidth allocation ratio is determined for each transmission queue; when the vehicle is not in a driving state, a second bandwidth allocation ratio is determined for each transmission queue. Specifically, the first bandwidth allocation ratio for the target transmission queue is greater than the second bandwidth allocation ratio for the target transmission queue, which is used to store data packets for driving safety-related services. In other words, the real-time requirement for data interaction for driving safety-related services is higher when the vehicle is in a driving state than when it is not in a driving state. Therefore, the first bandwidth allocation ratio allocated to the target transmission queue is higher when the vehicle is in a driving state than the second bandwidth allocation ratio allocated to the target transmission queue when the vehicle is not in a driving state.

[0078] For example, taking the four sending queues Q4, Q3, Q2 and Q1 shown in Table 2 above as an example, in the driving state, Q4:Q3:Q2:Q1=5:3:1:1; in the non-driving state, Q4:Q3:Q2:Q1=2:5:2:1.

[0079] The above implementation is illustrated using the example of a vehicle in driving or not in driving mode. However, in practice, the vehicle's state can be further refined to achieve a more precise bandwidth allocation.

[0080] For example, taking the non-driving state as an example, the specific state of the vehicle in the non-driving state can be detected. For example, if the vehicle is in the non-driving state and is in the OTA upgrade state, then the bandwidth allocation ratio of the sending queue corresponding to the user-unaware type of service can be higher than the bandwidth allocation ratio of other sending queues. For example, Q4:Q3:Q2:Q1=1:1:1:7.

[0081] In another possible implementation, vehicles can also be scheduled based on class-based queuing (CBQ): traffic classes are defined according to complex rules such as service source, protocol type, destination address, etc., and different bandwidth ratios are allocated to different traffic classes in combination with the actual service needs of the vehicles.

[0082] By configuring the bandwidth ratio of each transmission queue differently based on the different states of the vehicle, network resources can be allocated on demand. This ensures the timeliness of transmission of traffic safety services while effectively maintaining the functional availability of non-safety services, thereby improving the utilization efficiency of network resources.

[0083] In one possible implementation, the target bandwidth allocation ratio for each transmission queue can also be obtained by adjusting the actual bandwidth used by each transmission queue under historical weak network conditions, so that the bandwidth allocation is more in line with actual usage and thus improves resource utilization.

[0084] In this implementation, the vehicle can obtain its historical driving data, which includes the historical bandwidth characteristics of each transmission queue when the vehicle was in different in-vehicle scenarios under historical weak network conditions. The historical bandwidth characteristics can be the actual bandwidth used by each transmission queue. Then, based on the historical bandwidth characteristics of each transmission queue when the vehicle was in a non-assisted driving scenario under historical weak network conditions, the initial bandwidth allocation ratio for each transmission queue is adjusted to obtain the target bandwidth allocation ratio for each transmission queue.

[0085] For example, the vehicle can calculate the average bandwidth usage ratio of each sending queue in historical bandwidth data, and based on the average bandwidth usage ratio of each sending queue, correct the initial bandwidth allocation ratio of each sending queue to obtain the target bandwidth allocation ratio of each sending queue.

[0086] For example, taking the four transmission queues Q4, Q3, Q2, and Q1 shown in Table 2, with initial bandwidth allocation ratios of Q4: 50%, Q3: 20%, Q2: 20%, and Q1: 10%, and based on historical driving data, the average bandwidth usage ratios for Q4, Q3, Q2, and Q1 are 60%, 15%, 15%, and 10%, respectively. Based on this historical driving data, the initial bandwidth allocation ratios for Q4, Q3, Q2, and Q1 are adjusted. This adjustment corrects the initial bandwidth allocation ratio for each transmission queue to its corresponding average bandwidth usage ratio, effectively using the average bandwidth usage ratio of each transmission queue as the target bandwidth allocation ratio for that queue.

[0087] Alternatively, the target bandwidth allocation ratio for each sending queue can be calculated based on the initial bandwidth allocation ratio, the average bandwidth usage ratio, and a preset weighting coefficient. The weighting coefficient can be set based on experience or experimental data, and this embodiment does not limit this. An exemplary method for calculating the target bandwidth allocation ratio is as follows: Target bandwidth allocation ratio = Weighting coefficient × Initial bandwidth allocation ratio + (1 - Weighting coefficient) × Average bandwidth used Taking a preset weighting coefficient of 0.5 as an example, the target bandwidth allocation ratio for Q4 is 0.5 × 50% + 0.5 × 60% = 55%; the target bandwidth allocation ratio for Q3 is 0.5 × 20% + 0.5 × 15% = 17.5%; the target bandwidth allocation ratio for Q2 is 0.5 × 20% + 0.5 × 15% = 17.5%; and the target bandwidth allocation ratio for Q1 is 0.5 × 10% + 0.5 × 10% = 10%. For an example, please refer to... Figure 4This diagram illustrates a method for correcting the initial bandwidth allocation ratio based on the average bandwidth usage ratio, as provided in an embodiment of this application. After correction, the target bandwidth allocation ratio for Q4 is 55%, for Q3 it is 17.5%, for Q2 it is 17.5%, and for Q1 it is 10%.

[0088] In practical applications, historical driving data under weak network conditions can be collected separately according to different vehicle states and used for correction, thereby achieving more refined adjustments. The specific adjustment methods can be referred to the content mentioned above, and will not be repeated here.

[0089] 2. Assisted driving scenarios.

[0090] When the target vehicle scenario is an assisted driving scenario, the vehicle can send data packets from multiple transmission queues in descending order of their service priorities. Among these, vehicle safety-related services have the highest priority. That is, data packets from the highest priority transmission queue are sent first, and only after all data packets in the highest priority queue have been sent will data packets from the next highest priority transmission queue be sent.

[0091] For example, if the business priority is sorted as follows: driving safety > heavy user experience > weak user experience > user-unaware data, the vehicle will first send the data packets in the sending queue corresponding to the driving safety category. After all the data packets in the sending queue corresponding to the driving safety category have been sent, the data packets in the sending queue corresponding to the heavy user experience category will be sent, and so on.

[0092] In another possible implementation, the vehicle can also schedule data packets in each transmission queue based on Earliest Deadline First (EDF): the vehicle marks a task deadline for each data packet according to the service urgency of each data packet. The task deadline is used to indicate the latency requirement of the data packet. Based on this, when sending data packets in multiple transmission queues, the data packet with the earliest deadline can be sent first.

[0093] Since vehicles assume partial control, and vehicle control relies heavily on large amounts of real-time data (such as sensor data, V2X data, and cloud platform commands), interruptions or delays in these crucial data transmissions due to weak network conditions can lead to loss of vehicle control and even serious traffic accidents. Therefore, in assisted driving scenarios, it is essential to prevent other services from monopolizing network bandwidth resources and prioritize the timely transmission of data packets for driving safety-related services to ensure vehicle safety.

[0094] In one possible implementation, the vehicle can also combine map data and / or Global Positioning System (GPS) to predict whether the vehicle is about to enter a weak network area, and thus predict that the vehicle's wireless network status will soon be in a weak network state, thereby activating the above scheduling method in advance.

[0095] In one possible implementation, the vehicle also includes multiple electronic control units (ECUs) for generating data packets of various service types. For example, the multiple ECUs include, but are not limited to, advanced driving assistance system (ADAS) controllers, in-vehicle infotainment (IVI) hosts, gateways, and vehicle domain controllers.

[0096] The vehicle can receive data packets to be transmitted from a target electronic control unit (ECU), which can be any one of multiple ECUs. Then, the service type corresponding to the data packet to be transmitted is identified, and a priority identifier is assigned to the data packet based on the service type. Subsequently, the data packet to be transmitted can be mapped and stored in the corresponding transmission queue according to the priority identifier.

[0097] For example, the central gateway in the vehicle can receive the data packet to be sent from the target electronic control unit, add a priority identifier to the data packet according to the service type of the data packet, and then send the data packet carrying the priority identifier to the TBOX module. The TBOX module parses the priority identifier in the data packet to be sent and puts the data packet into the corresponding sending queue based on the parsed priority identifier.

[0098] Alternatively, the vehicle's internal TBOX module can add priority identifiers to data packets to be sent. For example, data flow characteristics (source IP / port, destination IP / port, protocol type, application layer information, etc.) can be uniformly identified at the TBOX, and QoS tags can be uniformly added by the TBOX. This reduces the burden on the ECU and facilitates centralized management strategies.

[0099] Alternatively, data packets from some important or intelligent ECUs (such as IVI, ADAS) can have priority identifiers added by their respective ECUs, while data packets from other ECUs can have priority identifiers added by the central gateway or TBOX module.

[0100] The priority identifier indicates the service type of the data packet to be sent. Service types include driving safety, high user experience, low user experience, and user-unaware service. In practical applications, based on the vehicle's service requirements, the service can be divided into more or fewer types, and this embodiment does not limit this. For example, the priority identifier may be a QoS tag.

[0101] In another possible implementation, the priority identifier for the data packet to be sent can also be added by the target electronic control unit. The target electronic control unit can directly add the corresponding priority identifier based on the service type of the data packet to be sent.

[0102] In one possible implementation, the priority identifier of the data packet to be sent can be added to the target field of the packet header. For example, taking an Internet Protocol (IP) data packet as an example, the location of the priority identifier addition in this embodiment will be illustrated. Please refer to... Figure 5 This is a schematic diagram of the structure of an IP data packet provided in an embodiment of this application. Figure 5 As shown, this IP packet consists of an IP header and an IP payload. The IP header includes a Type of Service field, which comprises a Differentiated Services Code Point (DSCP) field and an Explicit Congestion Notification (ECN) field. The IP payload primarily carries the actual data content to be transmitted. The DSCP value is 3, indicating that the priority of this IP packet is "3".

[0103] It should be understood that the embodiments of this application use a priority identifier of 3 as an example, but in actual applications, the priority identifier of the data packet to be sent can be represented by other characters or other values, depending on the actual priority setting rules, and the embodiments of this application do not limit this.

[0104] In another possible implementation, the priority identifier of the data packet to be sent can be the Priority Code Point (PCP) field carried in the Virtual Local Area Network (VLAN) tag (802.1Q / p) of the Ethernet frame. The TBOX parses the VLAN PCP value before routing to obtain the priority identifier of the data packet.

[0105] For example, please refer to Figure 6 This is a schematic diagram illustrating the flow of data packets within a vehicle, as provided in an embodiment of this application. Figure 6 As shown, the data packets are generated by various electronic control units within the vehicle (such as...). Figure 6 The data packets are generated by the in-vehicle ECUs (ECU-1, ECU-2, and ECU-3) shown in the diagram. Each electronic control unit assigns a priority tag (QoS tag) to the data packet based on its service type, and then sends the data packet carrying the priority tag to the TBOX via Ethernet. The TBOX receives the data packets generated by each electronic control unit, parses the priority tags in these data packets, and places the data packet into the corresponding priority transmission queue based on the priority tag, waiting to be transmitted to the corresponding external device via a cellular network (such as a 4G or 5G network). The scheduling strategies and network status monitoring involved in transmitting the data packets can be referred to the content described above, and will not be repeated here.

[0106] In this implementation, by adding a priority identifier to the data packets to be sent, the vehicle can identify data of different service types by recognizing the priority identifier. Thus, in a weak network environment, the vehicle can prioritize the processing of critical services based on the current target vehicle scenario, thereby ensuring the service quality of critical services in a weak network environment.

[0107] The following is combined with Figure 7 The diagram shows a data transmission method. Figure 2 The data transmission method provided in the embodiments of this application will be illustrated.

[0108] S701 monitors the vehicle's current wireless network status in real time and determines whether the vehicle's wireless network is in a weak state.

[0109] The specific implementation method for determining whether the vehicle's wireless network is in a weak network state can be referred to the content described above, and will not be repeated here.

[0110] S702 determines the target scheduling strategy that matches the target vehicle scenario from multiple scheduling strategies based on the current target vehicle scenario.

[0111] The descriptions of the target vehicle scenario and the target scheduling strategy can be found in the preceding text, as can the specific implementation methods for determining the target scheduling strategy based on the target vehicle scenario. They will not be repeated here.

[0112] S703 schedules and sends data packets from multiple sending queues according to the target scheduling strategy.

[0113] The specific implementation method for scheduling and sending data packets in multiple sending queues according to the target scheduling strategy can be referred to the content described above, and will not be repeated here.

[0114] S704 sends data packets according to the original scheduling rules.

[0115] The description of the original scheduling rules can be found in the previous text, and will not be repeated here.

[0116] In this embodiment, when the vehicle's wireless network is in a weak network state, a target scheduling strategy matching the target vehicle scenario is dynamically selected based on the current target vehicle scenario. Since each transmission queue corresponds to a service priority, and the target scheduling strategy indicates the data transmission method matching the target vehicle scenario, data packets in multiple transmission queues are sent based on the target scheduling strategy. This effectively ensures that critical service data in the target vehicle scenario is processed first when transmitting data, thereby guaranteeing the timeliness of transmission of critical service data in the target vehicle scenario in a weak network environment.

[0117] Based on the same inventive concept, embodiments of this application provide a data transmission device for implementing any of the above-described data transmission methods, for example... Figure 3 or Figure 7 The data transmission method shown is described, and the data transmission device can also realize the functions of the vehicle mentioned above.

[0118] Please refer to Figure 8 This is a schematic diagram of the structure of a data transmission device provided in an embodiment of this application. Figure 8 As shown, the data transmission device 800 includes a determining module 801, a sending module 802, and a marking module 803. This data transmission device 800 can be applied to vehicles.

[0119] The determination module 801 is used to determine the target vehicle scenario when the vehicle's wireless network is detected to be in a weak network state; and to determine a target scheduling strategy that matches the target vehicle scenario from a set of preset scheduling strategies, wherein the target scheduling strategy is used to indicate the data transmission method of multiple transmission queues in the target vehicle scenario, and each transmission queue is used to associate data packets to be transmitted with different service priorities; the transmission module 802 is used to schedule and transmit data packets in multiple transmission queues according to the target scheduling strategy.

[0120] In one possible implementation, the sending module 802 is specifically used to: when the target vehicle scenario is a non-assisted driving scenario, obtain the target bandwidth allocation ratio corresponding to each of the multiple sending queues; determine the actual available bandwidth corresponding to each sending queue based on the target bandwidth allocation ratio corresponding to each sending queue and the total available bandwidth of the vehicle in the current wireless network state; and control the sending rate of data packets in the multiple sending queues based on the actual available bandwidth corresponding to each sending queue.

[0121] In one possible implementation, the sending module 802 is specifically used to: identify whether the vehicle is in a driving state; when the vehicle is in a driving state, determine a first bandwidth allocation ratio corresponding to each sending queue; when the vehicle is not in a driving state, determine a second bandwidth allocation ratio corresponding to each sending queue; wherein, the first bandwidth allocation ratio corresponding to the target sending queue is higher than the second bandwidth allocation ratio corresponding to the target sending queue, and the target sending queue is used to store data packets of driving safety services.

[0122] In one possible implementation, the sending module 802 is specifically used to: obtain historical driving data of the vehicle, including historical bandwidth characteristics of each sending queue when the vehicle is in different vehicle scenarios under historical weak network conditions; and correct the initial bandwidth allocation ratio corresponding to each sending queue according to the historical bandwidth characteristics of each sending queue when the vehicle is in a non-assisted driving scenario under historical weak network conditions, so as to obtain the target bandwidth allocation ratio corresponding to each sending queue.

[0123] In one possible implementation, the sending module 802 is specifically used to: when the target vehicle scenario is an assisted driving scenario, send data packets in multiple sending queues in descending order according to the service priorities corresponding to multiple sending queues, wherein the priority of vehicle driving safety services is the highest service priority.

[0124] In one possible implementation, the determining module 801 is specifically used to: determine the target driving safety level corresponding to the vehicle based on the target vehicle scenario, wherein the target driving safety level is used to indicate the degree of real-time data interaction requirements of the vehicle for driving safety-related services in the target vehicle scenario; and determine data scheduling rules that have a mapping relationship with the driving safety level based on the target driving safety level, as the target scheduling strategy.

[0125] In one possible implementation, the vehicle includes multiple electronic control units (ECUs) for generating data packets of various service types. The data transmission device 800 further includes a marking module 803, which is used to: receive data packets to be transmitted from a target ECU before scheduling and transmitting data packets in multiple transmission queues according to a target scheduling strategy; identify the service type corresponding to the data packets to be transmitted and mark the data packets to be transmitted with a priority identifier according to the service type; and map and store the data packets to be transmitted into the corresponding transmission queue according to the priority identifier.

[0126] Based on the same inventive concept, embodiments of this application provide a vehicle, the device being used to implement any of the above-described data transmission methods, for example... Figure 3 or Figure 7 The data transmission method shown is illustrated, and the device can also be used to implement the functions of the vehicle described above.

[0127] Please refer to Figure 9 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Figure 9 As shown, the vehicle 900 includes at least one processor 901 and a memory 902 communicatively connected to the at least one processor 901.

[0128] The processor 901 can be a general-purpose processor or a dedicated processor. For example, the processor 901 may include a baseband processor or a central processing unit (CPU). The baseband processor can be used to process communication protocols and communication data. The CPU can be used to control the vehicle 900, execute software programs, and / or process data. Different processors can be independent devices or integrated into one or more processing circuits, for example, integrated onto one or more application-specific integrated circuits (ASICs). In one embodiment, memory 902 stores instructions that can be executed by at least one processor 901. At least one processor 901 implements the functions of the aforementioned vehicle by executing the instructions stored in memory 902, and correspondingly, can also implement the steps performed by the aforementioned vehicle. In this embodiment, the vehicle 900 can also implement the function of the preceding data transmission device 800, and at least one processor 901 in the vehicle 900 can also implement the functions of the preceding determination module 801, the sending module 802 and the marking module 803.

[0129] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements any of the data transmission methods described above, for example... Figure 3 or Figure 7 The data transmission method shown.

[0130] Based on the same inventive concept, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements any of the data transmission methods described above, for example... Figure 3 or Figure 7 The data transmission method shown.

[0131] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or as a combination of hardware and software modules within the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor executes the instructions in the memory, combining them with its hardware to complete the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0132] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0133] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0135] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0136] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0137] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0138] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data transmission method, characterized in that, Applied to vehicles, the vehicle wirelessly communicates with external devices, wherein the external devices are devices that have data interaction needs with the vehicle, the method includes: If the vehicle's wireless network is detected to be in a weak state, determine the target in-vehicle scenario in which the vehicle is currently located. Based on the target vehicle scenario, a target scheduling strategy matching the target vehicle scenario is determined from a plurality of preset scheduling strategies. The target scheduling strategy is used to indicate the data transmission method of multiple transmission queues in the target vehicle scenario. The plurality of transmission queues are used to associate data packets to be transmitted with different service priorities. The target vehicle scenario is a non-assisted driving scenario or an assisted driving scenario. According to the target scheduling strategy, the data packets in the multiple sending queues are scheduled to be sent. The step of determining a target scheduling strategy that matches the target vehicle scenario from a set of preset scheduling strategies, based on the target vehicle scenario, includes: Based on the target vehicle scenario, the target driving safety level corresponding to the vehicle is determined, wherein the target driving safety level is used to indicate the degree of real-time data interaction requirement of the vehicle for driving safety-related services in the target vehicle scenario; Based on the target driving safety level, a data scheduling rule that has a mapping relationship with the target driving safety level is determined, which serves as the target scheduling strategy.

2. The method according to claim 1, characterized in that, When the target vehicle scenario is a non-assisted driving scenario, the step of scheduling and sending data packets in the plurality of sending queues according to the target scheduling strategy includes: Obtain the target bandwidth allocation ratio corresponding to each of the plurality of sending queues; The actual available bandwidth corresponding to each transmission queue is determined based on the target bandwidth allocation ratio corresponding to each transmission queue and the total available bandwidth of the vehicle in the current wireless network state. The transmission rate of data packets in the multiple transmission queues is controlled based on the actual available bandwidth corresponding to each transmission queue.

3. The method according to claim 2, characterized in that, The step of obtaining the target bandwidth allocation ratio corresponding to each of the plurality of sending queues includes: Identify whether the vehicle is in motion; When the vehicle is in motion, determine the first bandwidth allocation ratio corresponding to each transmission queue; When the vehicle is not in a driving state, determine the second bandwidth allocation ratio corresponding to each transmission queue; In each of the sending queues, the first bandwidth allocation ratio corresponding to the target sending queue is higher than the second bandwidth allocation ratio corresponding to the target sending queue, and the target sending queue is used to store data packets for driving safety services.

4. The method according to claim 2, characterized in that, The step of obtaining the target bandwidth allocation ratio corresponding to each of the plurality of sending queues includes: Obtain the historical driving data of the vehicle, which includes the historical bandwidth characteristics of each transmission queue when the vehicle is in different vehicle scenarios under historical weak network conditions; Based on the historical bandwidth characteristics of each transmission queue when the vehicle is in the unassisted driving scenario under historical weak network conditions, the initial bandwidth allocation ratio corresponding to each transmission queue is corrected to obtain the target bandwidth allocation ratio corresponding to each transmission queue.

5. The method according to claim 1, characterized in that, When the target vehicle scenario is an assisted driving scenario, the step of scheduling and sending data packets in the multiple sending queues according to the target scheduling strategy includes: Data packets in the multiple sending queues are sent in descending order according to the service priorities corresponding to the multiple sending queues, wherein the vehicle driving safety service has the highest service priority.

6. The method according to any one of claims 1-5, characterized in that, The vehicle includes multiple electronic control units (ECUs) for generating data packets of various service types. Before scheduling and sending the data packets in the multiple sending queues according to the target scheduling strategy, the method further includes: Receive data packets to be sent from the target electronic control unit; Identify the service type corresponding to the data packet to be sent, and mark the data packet to be sent with a priority identifier according to the service type; Based on the priority identifier, the data packets to be sent are mapped and stored in the corresponding sending queue.

7. A data transmission device, characterized in that, Applied to vehicles, the vehicle communicates wirelessly with external devices, wherein the external devices are devices that have data interaction needs with the vehicle, and the data transmission device includes: The determination module is configured to determine the target vehicle scenario when the vehicle's wireless network is detected to be in a weak network state; and to determine a target scheduling strategy matching the target vehicle scenario from a set of preset scheduling strategies, wherein the target scheduling strategy is used to indicate the data transmission method of multiple transmission queues in the target vehicle scenario, and each transmission queue is used to associate data packets to be transmitted with different service priorities; the target vehicle scenario is a non-assisted driving scenario or an assisted driving scenario. The sending module is used to schedule and send data packets in the plurality of sending queues according to the target scheduling strategy; The determining module is specifically used for: Based on the target vehicle scenario, the target driving safety level corresponding to the vehicle is determined, wherein the target driving safety level is used to indicate the degree of real-time data interaction requirement of the vehicle for driving safety-related services in the target vehicle scenario; Based on the target driving safety level, a data scheduling rule that has a mapping relationship with the target driving safety level is determined, which serves as the target scheduling strategy.

8. A vehicle, characterized in that, include: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the method according to any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1-6.

Images