Traffic scheduling method based on Internet of Vehicles, storage medium and vehicle

Abstract

The invention discloses a traffic scheduling method based on the Internet of Vehicles, a storage medium and a vehicle, and the method comprises the steps: obtaining a network request initiated by a vehicle-mounted application in the vehicle in real time, and obtaining multi-dimensional context information according to the network request; identifying a current first communication demand of the vehicle-mounted application according to the multi-dimensional context information; according to the first communication demand, dynamically generating a flow distribution strategy aiming at the first communication demand in real time; and according to the traffic distribution strategy, carrying out differential traffic distribution on the vehicle-mounted application. According to the method, the communication demand of the vehicle-mounted application is identified by fusing multi-dimensional context information for comprehensive analysis, and a flow distribution strategy aiming at the communication demand is further dynamically formulated based on an identification result, so that refined and reasonable resource scheduling can be carried out aiming at diversified demands of different vehicle-mounted applications; accurate matching of communication requirements and resource allocation is realized, the flexibility of resource allocation is remarkably improved, and the utilization efficiency of network resources is integrally improved.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, specifically to a traffic scheduling method, storage medium, and vehicle based on vehicle networking. Background Technology

[0002] With the increasing demand for intelligent technology, vehicle-to-everything (V2X) technology has been widely applied in in-vehicle systems, driving the rapid development of automobiles towards intelligent connectivity. In this environment, V2X traffic exhibits significant characteristics such as high real-time performance, strong bursts, high concurrency, and massive data volumes, thus placing higher demands on network resource scheduling mechanisms.

[0003] Currently, common traffic scheduling mechanisms typically rely on fixed resource allocation strategies and static routing strategies to allocate traffic. However, in practical applications, these two routing strategies often lead to uneven network load, making it difficult to ensure reliable transmission of diverse data in the vehicle network environment, resulting in low resource utilization and a lack of ability to respond to emergencies.

[0004] Therefore, how to accurately match the communication needs of in-vehicle applications with network traffic allocation and effectively improve resource utilization has become an urgent technical problem to be solved. Summary of the Invention

[0005] In view of this, embodiments of this application provide a traffic scheduling method, storage medium, and vehicle based on the Internet of Vehicles (IoV). This method can identify the communication intent of the network requests of the in-vehicle applications through multi-dimensional context information of the network requests of the in-vehicle applications, and dynamically generate a traffic allocation strategy for the communication intent based on the communication intent, thereby achieving accurate matching between the communication needs of the in-vehicle applications and the network traffic allocation.

[0006] In a first aspect, embodiments of this application provide a traffic scheduling method based on the Internet of Vehicles (IoV), applied to an IoV-based traffic scheduling system. The method includes: acquiring network requests initiated by in-vehicle applications in real time, and acquiring multi-dimensional context information based on the network requests; identifying a first communication requirement of the in-vehicle application based on the multi-dimensional context information, wherein the first communication requirement is used to characterize the communication intent of the in-vehicle application initiating the network request; dynamically generating a traffic allocation strategy for the first communication requirement in real time; and performing differentiated traffic allocation for the in-vehicle application based on the traffic allocation strategy.

[0007] As one possible implementation of the first aspect, identifying the current first communication requirement of the vehicle application based on multi-dimensional contextual information includes: extracting semantic information contained in the multi-dimensional contextual information through a communication requirement identification model, and identifying the first communication requirement of the vehicle application based on the semantic information.

[0008] As one possible implementation of the first aspect, generating a traffic allocation strategy for the first communication requirement in real time and dynamically according to the first communication requirement includes: evaluating the priority level of the first communication requirement through a resource allocation decision model, and determining the traffic allocation strategy for the first communication requirement based on the priority level.

[0009] As a possible implementation of the first aspect, the method further includes: using the identified first communication requirement and the generated traffic allocation strategy as new training samples to train the resource allocation decision model in order to optimize the resource allocation decision model.

[0010] As one possible implementation of the first aspect, the method further includes: pre-setting a mapping table to characterize the mapping relationship between the service type of the vehicle and the service quality agreement grading standard; dynamically generating a traffic allocation strategy for the first communication requirement in real time according to the first communication requirement, including: determining the priority level of the first communication requirement according to the mapping table; and generating a traffic allocation strategy corresponding to the first communication requirement according to the priority level.

[0011] As a possible implementation of the first aspect, the method further includes: determining the number of currently active in-vehicle applications based on network requests initiated by in-vehicle applications; predicting the vehicle's second communication needs based on the number and the first communication needs, using the mapping relationship between multi-dimensional contextual information learned by the demand prediction model and changes in communication needs, wherein the second communication needs are the communication needs of the vehicle during subsequent driving; preloading data related to the second communication needs, and adjusting the traffic allocation strategy according to the second communication needs.

[0012] As one possible implementation of the first aspect, the first communication requirement includes at least one of the service type and service scenario of the network request corresponding to the service, and the multi-dimensional context information includes at least one of the vehicle status information, communication link status information, user interaction information and in-vehicle application information.

[0013] As one possible implementation of the first aspect, the vehicle-to-everything (V2X) traffic scheduling system includes: a cloud service platform, in which control components and microservice components provided by a service mesh are deployed; identifying the current first communication requirement of the in-vehicle application based on multi-dimensional context information, including: identifying the first communication requirement of the in-vehicle application through the microservice components based on multi-dimensional context information; dynamically generating a traffic allocation strategy for the first communication requirement in real time based on the first communication requirement, including: dynamically generating a traffic allocation strategy for the first communication requirement in real time through the microservice components to achieve dynamic traffic allocation; and performing differentiated traffic allocation for the in-vehicle application according to the traffic allocation strategy, including: performing differentiated traffic allocation for the in-vehicle application through the control component according to the traffic allocation strategy.

[0014] Secondly, embodiments of this application provide a computer-readable storage medium storing a computer program for executing the traffic scheduling method based on the Internet of Vehicles described in the first aspect.

[0015] Thirdly, embodiments of this application provide a vehicle comprising: a processor; and a memory for storing processor-executable instructions, wherein the processor is used to execute the vehicle-to-everything (V2X) traffic scheduling method described in the first aspect.

[0016] This application provides a traffic scheduling method, storage medium, and vehicle based on the Internet of Vehicles. The method identifies the communication needs of in-vehicle applications by integrating multi-dimensional contextual information for comprehensive analysis. Furthermore, it dynamically formulates a traffic allocation strategy for the communication needs based on the identification results. This method can perform refined and rational resource scheduling for the diverse needs of different in-vehicle applications, achieve precise matching between communication needs and resource allocation, significantly improve the flexibility of resource allocation, and improve the overall utilization efficiency of network resources. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the structure of a traffic scheduling system based on the Internet of Vehicles provided in an exemplary embodiment of this application.

[0019] Figure 2 This is a flowchart illustrating a traffic scheduling method based on the Internet of Vehicles provided in an exemplary embodiment of this application.

[0020] Figure 3 This is a schematic diagram of a mapping table that represents the mapping relationship between the service type of a vehicle and the Service Quality Agreement (SLA) grading standard, provided by an exemplary embodiment of this application.

[0021] Figure 4 This is a flowchart illustrating an exemplary embodiment of the present application of a method for adaptively adjusting traffic allocation strategies.

[0022] Figure 5 This is a timing diagram of traffic scheduling based on the Internet of Vehicles provided in an exemplary embodiment of this application.

[0023] Figure 6 This is a schematic diagram of the structure of a traffic scheduling device based on the Internet of Vehicles provided in an exemplary embodiment of this application.

[0024] Figure 7 This is a block diagram of an electronic device for traffic scheduling in a vehicle network, provided in an exemplary embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] Application Overview Vehicle-to-everything (V2X) technology aims to use vehicles as mobile intelligent nodes, leveraging information and communication technologies to achieve data interaction and collaborative computing between vehicles, between vehicles and cloud platforms, between vehicles and people, and between vehicles and roads. It is a comprehensive network technology that improves traffic safety, traffic efficiency, and the user's driving experience. Traffic scheduling technology is responsible for intelligently allocating network channels and bandwidth in resource-constrained communication environments to meet the business needs of in-vehicle applications. It is a key enabling and control core that ensures the realization of diverse V2X business requirements.

[0027] In related technologies, common traffic scheduling mechanisms typically rely on fixed resource allocation strategies and static routing strategies to allocate traffic. Specifically, fixed resource allocation strategies use preset resource allocation amounts (e.g., bandwidth, time slots, priorities, etc.) and strictly follow a pre-defined resource allocation template for traffic scheduling. Static routing-based resource allocation strategies select a fixed optimal path (e.g., a fixed routing algorithm based on the shortest hop count or a fixed routing algorithm based on a geographical region) to forward traffic. However, in practical applications, these two routing strategies often lead to uneven network load, making it difficult to ensure reliable transmission of diverse data in the vehicle-to-everything (V2X) environment. They also result in low resource utilization and a lack of ability to respond to emergencies, such as sudden surges in traffic during severe weather or traffic accidents.

[0028] To address the aforementioned issues, this application's embodiments creatively identify the communication intent of in-vehicle applications and then dynamically allocate traffic based on different communication intents. This achieves precise matching between the communication needs of services and the allocation of network resources, thereby meeting the diverse needs of vehicle networking applications and effectively improving resource utilization.

[0029] Various non-limiting embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0030] Exemplary vehicle-to-everything (V2X) traffic scheduling system Figure 1 This is a schematic diagram of the structure of a traffic scheduling system based on the Internet of Vehicles provided in some embodiments of this application. For example... Figure 1 As shown, the vehicle-to-everything (V2X) traffic scheduling system 100 may include at least one vehicle terminal 110, an edge gateway 120, and a cloud service platform 130, wherein each vehicle terminal is equipped with an in-vehicle application. At least one vehicle terminal 110 is connected to the edge gateway 120, and the edge gateway 120 is connected to the cloud service platform 130.

[0031] At least one in-vehicle application is deployed in each of the at least one vehicle terminal 110. For example, the in-vehicle application may be a smart mobility service application, such as autonomous driving, cooperative emergency braking (C-AEB), cooperative green wave speed guidance (C-GLOSA), etc.; the in-vehicle application may also be a cockpit information service and entertainment application, such as online audio and video streaming media (online music, internet radio, online video, and in-vehicle karaoke, etc.), navigation and map services (real-time traffic updates of online maps, map incremental update packages, etc.); the in-vehicle application may also be a vehicle remote service and status management application, such as remote vehicle control and status query, vehicle health diagnosis and data reporting, etc.

[0032] In some embodiments, at least one vehicle terminal 110 is used for data acquisition and instruction execution.

[0033] Edge gateway 120, acting as an intermediate hub connecting at least one vehicle terminal 110 and cloud service platform 130, is deployed at the network edge (e.g., cellular base station, regional server, etc.). It is responsible for receiving data from at least one vehicle terminal 110, performing preliminary processing, filtering, and aggregation on the data, and forwarding the processed data to cloud service platform 130. For example, edge gateway 120 can receive request data from in-vehicle applications of at least one vehicle terminal 110.

[0034] In some embodiments, the edge gateway 120 includes at least one edge node 121.

[0035] For example, edge node 121 may include a proxy component 1211 provided by the Istio service mesh, a Kubernetes node 1212, and a microservice component 1213. By introducing the proxy component provided by the Istio service mesh between microservices, network communication data between services can be intercepted and processed, enabling transparent control over interactions between services.

[0036] In some embodiments, the cloud service platform 130 can be the core processing and scheduling center of a vehicle-to-everything (V2X) traffic scheduling system, used for global resource management and traffic allocation. For example, the cloud service platform 130 can be built based on a container resource orchestration platform (e.g., a Kubernetes resource orchestration platform) and a microservice architecture. The Kubernetes container orchestration platform enables containerized deployment, resource scheduling, and management of applications. Utilizing Kubernetes' service discovery mechanism, a stable network entry point is provided for dynamically created or destroyed Pods, thereby achieving service discovery and load balancing between microservices.

[0037] Specifically, the cloud service platform 130 can be deployed in a container cluster (e.g., a Kubernetes cluster) 131. The architecture of the container cluster can be further divided into a control plane and a data plane. In the control plane, a container management component (Kubernetes Master component) 1311 and a control plane component 1312 provided by the Istio service mesh can be deployed to be responsible for cluster management, service governance policy formulation and distribution. In the data plane, at least one worker node 1313 can be deployed to host microservice pods running business logic.

[0038] In some embodiments, the Kubernetes cluster 131 can be a Kubernetes cluster of version 1.24, consisting of 50 nodes, including 20 control nodes (Kubernetes Master node 1312) and 30 worker nodes. Each node is configured with 16 cores and 64GB of RAM, which means that the total basic computing resources available for Kubernetes cluster scheduling and management are 16 CPU cores and 64GB of system memory.

[0039] In some embodiments, Calico3,23 is used as a network plugin to ensure low latency and isolation in cross-node container communication.

[0040] In some embodiments, the Istio service mesh uses Istio version 1.14 and implements traffic governance for 78 microservices through Sidecar auto-injection, including service discovery, circuit breaking and degradation, and Mutual Transport Layer Security (MTLS) encryption.

[0041] In some embodiments, the cloud service platform 130 further includes a database 132 and a microservice component 1213.

[0042] It should be noted that, Figure 1 The number of vehicle terminals, edge nodes, and worker nodes shown is merely an example and can be flexibly set according to actual needs. This application does not impose specific limitations on the number of vehicle terminals, edge nodes, and worker nodes.

[0043] Specifically, microservice component 1213 is used to design and decompose multiple microservices deployed in the cloud service platform 130, such as order service, scheduling service, routing service, and user service. The microservices in microservice component 1213 communicate with each other via Google Remote Procedure Call (GRPC), which improves data transmission efficiency by 40% compared to Hypertext Transfer Protocol (HTTP).

[0044] It should be noted that the microservice components in the edge gateway 120 and the microservice components in the cloud service platform 130 can be understood as the same components. The Kubernetes nodes in the edge gateway 120 and the Kubernetes Master component 1311 in the cloud service platform 130 differ in deployment form and division of responsibilities. The Kubernetes nodes in the edge node 121 are deployed on a smaller scale and are more dispersed, while the Kubernetes nodes deployed in the Kubernetes component 1311 in the cloud service platform 130 are deployed on a larger scale and are more concentrated. The Kubernetes Master component is the command center of the Kubernetes cluster and can manage the Kubernetes nodes.

[0045] In summary, the vehicle-to-everything (V2X) traffic scheduling system employs a layered collaborative architecture consisting of cloud services built on a Kubernetes cluster, edge gateways deployed at the network edge, and vehicle terminals. By further introducing microservices and service mesh technologies, it achieves fine-grained and automated traffic scheduling, thereby possessing highly flexible and scalable traffic management capabilities.

[0046] In some embodiments, the vehicle-to-everything (V2X) traffic scheduling method described below can be performed by the V2X-based traffic scheduling system 100.

[0047] Exemplary traffic scheduling method based on vehicle-to-everything (V2X) network To further explain Figure 1 The present application illustrates the specific process by which a vehicle-to-everything (V2X) traffic scheduling system allocates traffic to in-vehicle applications. It also provides an exemplary flowchart of a V2X traffic scheduling method. Figure 2 This vehicle-to-everything (V2X)-based traffic scheduling method is applied to a V2X-based traffic scheduling system 100. During the traffic scheduling process: like Figure 2 As shown, the following steps can be performed through the vehicle-to-everything (V2X) traffic scheduling system 110: S210: Real-time acquisition of network requests initiated by in-vehicle applications and acquisition of multi-dimensional context information based on the network requests.

[0048] In-vehicle applications can be software applications that are integrated into a vehicle and used to provide specific functions, services, or experiences for the occupants (drivers and passengers) inside the vehicle. For example, in-vehicle applications may include one or more combinations of smart mobility service applications, cockpit information service and entertainment applications, and vehicle remote service and status management applications.

[0049] It should be noted that the in-vehicle application described in the above embodiments is merely an example. The in-vehicle application can also be any other application that can be implemented. This application does not specifically limit the type of in-vehicle application.

[0050] A network request can be an interaction process initiated by an in-vehicle application to a target (e.g., a cloud service platform) in order to obtain a specific function or service response.

[0051] In some embodiments, based on the core functions and communication modes of in-vehicle applications, in-vehicle applications deployed in vehicles can be divided into vehicle-to-everything (V2X) applications and non-V2X applications.

[0052] Multi-dimensional contextual information can be a collection of multiple data points used to characterize the current network state and the network request status of in-vehicle applications. For example, multi-dimensional contextual information may include at least one of vehicle status information, communication link information, user interaction information, and in-vehicle application information.

[0053] Specifically, multi-dimensional contextual information can include user behavior information, vehicle status information, network request information, network status information, and application information. User behavior information can include user identity information and user-performed vehicle operations (e.g., activated in-vehicle applications). Vehicle status data can include vehicle CAN bus data (e.g., vehicle speed, acceleration, braking status, turn signal status, tire pressure, etc.) and environmental perception data, such as geographic location information (GPS coordinates), weather conditions, road type, and current traffic conditions. Network request information includes the target domain name or IP address (e.g., map service API, entertainment server, etc.), protocol type (e.g., Message Queuing Telemetry Transport (MQTT) protocol, gRPC protocol), and the size and frequency of the sent message. Network status information can include the strength of the received signal in real time, network type, end-to-end latency, network jitter, and packet loss rate. Application information can include the application ID, process name, and digital signature (used to identify whether the requesting application is a trusted and secure application) of the in-vehicle application sending the request.

[0054] In some embodiments, the vehicle terminal may periodically report its status information, including vehicle status information and network status information, to the target (e.g., a cloud service platform). For example, a timer may be set in the vehicle system so that the vehicle system automatically triggers an information report each time a preset period is reached.

[0055] In some embodiments, the target end (e.g., a cloud service platform) may also proactively initiate a status information query request to the vehicle terminal based on management or service needs.

[0056] In some embodiments, the vehicle terminal may also proactively report to the target end (e.g., cloud service platform) immediately when it detects a specific event or a breach of a state threshold, such as a safety warning event (collision detection or sudden drop in tire pressure).

[0057] In some embodiments, the target end (e.g., a cloud service platform) can obtain user operation intent (i.e., the aforementioned user behavior information) and application information by parsing the data packets of network requests sent by the vehicle terminal.

[0058] S220: Identify the primary communication requirement of the in-vehicle application based on multi-dimensional contextual information.

[0059] The first communication requirement is used to characterize the communication intent of the network request currently initiated by the vehicle application, and can be a communication intent label rich in semantic information.

[0060] In some embodiments, the first communication requirement may include at least one of the service type and service scenario of the network request corresponding to the service of the vehicle application.

[0061] As an example, the first communication requirement may include the service type of the network request corresponding to the service, and the service intent determined according to the service type. For example, the communication requirement for an emergency braking request automatically sent by the in-vehicle application to surrounding vehicles before a collision may include: service type: emergency braking, service intent: safety warning; the communication requirement for a user's request to remotely unlock the car door via a mobile terminal may include: service type: interaction, service intent: remote interactive control; the communication requirement for a passenger's video or music playback request clicked on the in-vehicle screen may include: service type: in-vehicle service, service intent: entertainment.

[0062] As an example, the first communication requirement can include business type and business scenario. The importance of network requests can be determined based on the business type and scenario. Based on the different levels of importance and urgency, network requests can be divided into critical business requests and non-critical business requests. Specifically, business requests that are directly related to vehicle driving safety and user safety, such as vehicle safety systems, emergency call services, navigation, and driver assistance functions, can be classified as critical business requests; while business requests that are mainly for entertainment and have no direct impact on vehicle operation, such as music streaming and video streaming, can be classified as non-critical business requests.

[0063] It should be noted that the above-described method of dividing network requests for vehicle applications into services is merely an example, and this application does not impose any specific limitations on the method of dividing network requests for vehicle applications into services.

[0064] By integrating multi-dimensional contextual information for comprehensive analysis, the communication requirements of in-vehicle applications are identified. Cross-validation from multiple dimensions significantly improves the accuracy of communication requirement identification. Furthermore, the identification results contain rich contextual semantic information, providing semantically understood decision-making basis for subsequent resource allocation decisions, thus making the final resource allocation decision more aligned with business logic.

[0065] In some embodiments, a first communication requirement of an in-vehicle application can be identified using a communication requirement identification model based on multi-dimensional contextual information. Specifically, the communication requirement model extracts semantic information included in the multi-dimensional contextual information and identifies the first communication requirement of the in-vehicle application based on this semantic information.

[0066] In some embodiments, the communication demand identification model can be a deep learning-based network model. For example, the communication demand identification model can be a convolutional neural network model (CNN), a long short-term memory network (LSTM) model, or a Transformer time series model. For instance, time series network data can be processed by a CNN, and continuous vehicle state sequences can be processed by an LSTM model or a Transformer time series model.

[0067] In some embodiments, the multi-dimensional context information associated with the network request is input into the communication requirement identification network to obtain the communication requirement corresponding to the network request, such as the business type and business scenario corresponding to the network request.

[0068] S230. Based on the first communication requirement, dynamically generate a traffic allocation strategy for the first communication requirement in real time.

[0069] S240. Based on the traffic allocation strategy, differentiate traffic allocation is performed for in-vehicle applications.

[0070] Considering that the network requests of different in-vehicle applications have different service requirements (communication requirements) and urgency levels, in order to meet the diverse needs of in-vehicle applications, in some embodiments, an allocation strategy is dynamically generated based on the communication requirements of the network requests of the in-vehicle applications and the current network status, so as to achieve differentiated traffic allocation for different in-vehicle applications.

[0071] In some embodiments, a traffic allocation strategy for the first communication requirement can be adaptively generated through a resource allocation decision model based on the first communication requirement obtained in the aforementioned S220.

[0072] Among them, the resource allocation decision model is used to characterize the mapping relationship between the first communication demand and the traffic allocation strategy.

[0073] In some embodiments, the resource allocation model assesses the priority of a first communication need by combining communication requirements and the current communication link status, formulates a traffic allocation strategy for communication needs based on the criterion of prioritizing traffic allocation to higher-priority communication needs, and achieves differentiated traffic allocation so that communication needs and resource allocation are accurately matched.

[0074] For example, the first communication requirement includes a service type. The latency requirement (which can be understood as urgency) of the service can be determined based on its service type, and the priority level of the service can be determined according to the different latency requirements. For example, network requests for services with high latency requirements (e.g., response latency requirement within 10ms) can be marked as high priority; network requests for services with moderate latency requirements (e.g., response latency requirement between 10ms and 100ms) can be marked as medium priority; and network requests for services with low latency requirements (e.g., greater than 100ms) can be marked as low priority. For example, network requests for advanced autonomous driving and emergency braking can be marked as high priority; network requests for real-time navigation can be marked as medium priority; and network requests for vehicle monitoring or in-vehicle entertainment can be marked as low priority. Traffic is allocated preferentially to high-priority network requests to ensure low-latency transmission of critical business data.

[0075] As an example, the first communication requirement can include the service type and service scenario. Considering that in practical applications, the urgency of the same type of service may change in different service scenarios—that is, the priority level of the same type of service may differ depending on the service scenario—the service scenario is added to the criteria for determining priority. Specifically, when the vehicle is traveling at high speed, video service requests are considered a risk of driver distraction and are marked as low priority; while when the vehicle is charging or waiting, the same video service requests are considered passenger entertainment and can be assigned medium priority, ensuring the accuracy and flexibility of resource allocation.

[0076] In some embodiments, a mapping table representing the mapping relationship between vehicle service types and service quality agreement (SQA) grading standards can be pre-set. The resource allocation model uses this mapping table to assess the priority level of a first communication requirement and generates a traffic allocation strategy corresponding to the first communication requirement based on the priority level. For example, the mapping table may include the type of in-vehicle application and its corresponding latency, reliability, and bandwidth requirements. For instance, the latency requirement for advanced applications like autonomous driving is less than 5ms, the reliability requirement is 99.999%, and the bandwidth requirement is 1Gbps. More details about the mapping table can be found in [link to documentation]. Figure 3 .

[0077] In some embodiments, the resource allocation decision model can be a deep reinforcement learning model. The deep reinforcement learning model can be trained using historical decision information as training samples, enabling it to learn the mapping relationship between communication demands and traffic allocation strategies. Specifically, the state space of the deep reinforcement learning model can include historical allocation information of in-vehicle applications, specifically including historical multi-dimensional contextual information of the in-vehicle applications, communication demands, network state information, and allocation strategies (e.g., historical base station connection information, historical resource allocation information, historical data rates, and historical channel gains). The action space can include historical allocation strategies (e.g., decision information on historical base station resource allocation in the in-vehicle system).

[0078] For example, training samples can be used to enable the resource allocation decision model to learn the mapping relationship between communication requirements and traffic allocation strategies. Finally, the communication requirements of the network requests of the vehicle application are input into the resource allocation decision model. The resource allocation decision model outputs a traffic allocation strategy for the communication requirements based on the learned mapping relationship between communication requirements and traffic allocation.

[0079] Since communication requirements contain information across multiple dimensions, such as service type and service scenario, in order to facilitate the subsequent resource allocation decision model in determining traffic allocation strategies, in some embodiments, after obtaining the relevant data on the communication requirements of the in-vehicle application, the communication requirement data is preprocessed. For example, a multi-objective joint optimization algorithm can be used to preprocess the communication requirement data, transforming multiple objective functions into a single objective function through weighted summation. For instance, the service type, service scenario, and priority level in the communication requirements can be weighted and summed to obtain a total score, which is then used as the criterion for traffic allocation in the subsequent resource allocation decision model. Alternatively, a hierarchical sequence method can be used to sort multiple objectives according to their priority levels. This application does not specifically limit the preprocessing method for the communication requirement data.

[0080] It should be noted that communication demand data can also be directly input into the resource allocation decision model without preprocessing.

[0081] An adaptive traffic scheduling mechanism is constructed based on a communication demand identification model and a traffic allocation strategy model. First, the business scenario and business type corresponding to the business requests of the vehicle application are obtained. Then, different priorities are assigned to different business requests according to the importance and urgency of the business scenario. Differentiated traffic allocation is carried out according to the different priorities, and traffic is allocated to high-priority business requests first to ensure low-latency transmission of data for critical business.

[0082] Considering the diverse user needs in practical applications, and to make traffic allocation strategies more reasonable, some embodiments further predict changes in communication demand (e.g., potential future communication needs), and further adjust the traffic allocation strategy based on the prediction results to adapt to complex traffic environments and diverse user needs. More details on changes in communication demand and adjustments to traffic allocation strategies can be found in [link to relevant documentation]. Figure 4 The description of its embodiments.

[0083] In some embodiments, during practical applications, new communication requirements and allocation strategies are used as new training samples to continuously train and update the resource allocation decision model, thereby constructing a dynamic resource allocation decision model and ensuring the accuracy of the resource allocation decision model.

[0084] In summary, by acquiring data requests from in-vehicle applications in real time and obtaining related multi-dimensional contextual information, a data foundation is laid for accurately identifying the real-time communication needs of in-vehicle applications. Furthermore, based on the identified communication needs containing semantic information, dynamic traffic allocation strategies can be formulated for those needs. This enables refined and rational resource scheduling for the diverse needs of different in-vehicle applications, achieving precise matching between communication needs and resource allocation. This significantly improves the flexibility of resource allocation, effectively responding to sudden business disruptions and ensuring a smooth user experience while improving the overall efficiency of network resource utilization.

[0085] Exemplary method for adaptively adjusting traffic allocation strategy To further illustrate the process of adjusting the traffic allocation strategy, some embodiments of this application also provide a flowchart of a method for adaptively adjusting the traffic allocation strategy. Figure 4 ).

[0086] like Figure 4 As shown, the following steps can be performed through the vehicle-to-everything (V2X) traffic scheduling system 110: S410. Determine the number of currently active in-vehicle applications based on network requests initiated by in-vehicle applications.

[0087] S420. Based on the quantity and the first communication requirement, predict the vehicle's second communication requirement by learning the mapping relationship between multi-dimensional contextual information and changes in communication requirement through the demand prediction model.

[0088] The second communication requirement is the communication requirement of the vehicle during subsequent driving, that is, the communication requirement that may occur in the future.

[0089] S430: Preload data related to the second communication requirement, and adjust the traffic allocation strategy according to the second communication requirement.

[0090] In some embodiments, the number of in-vehicle applications that initiate network requests in the current vehicle can be counted to determine the number of currently active in-vehicle applications.

[0091] In some embodiments, the type of in-vehicle application that initiated the network request by the current vehicle can also be obtained, and the number of in-vehicle applications of each type currently active can be determined.

[0092] In some embodiments, a demand forecasting model can be trained using large-scale historical communication demand data as samples, enabling the demand forecasting model to learn the mapping relationship between multi-dimensional contextual information and the changing trends of communication demand.

[0093] In some embodiments, the demand forecasting model can be a machine learning model; for example, the demand forecasting model can be a deep learning model, such as an LSTM model or a Transformer time series model.

[0094] In some embodiments, in order to adapt more flexibly to changes in business needs, a demand forecasting model can be used to predict the trend of communication demand changes in the short term. For example, the demand forecasting model can be used to predict the communication needs that may arise and the priority level of the communication needs. For the upcoming communication needs, the corresponding resource preparations can be completed in advance, and the traffic allocation strategy can be adjusted according to the communication needs and priority level, so that the traffic allocation strategy is forward-looking and can better cope with changes in communication needs.

[0095] As an example, a vehicle is currently driving into a tunnel with poor 5G signal coverage, while the navigation system is planning its route. The demand forecasting model predicts continued communication needs for navigation, but available resources may decrease. Therefore, "pre-caching high-precision map data" is marked as a high-priority critical service, and the resource allocation strategy model prioritizes allocating bandwidth to it within the specified window to complete data preloading.

[0096] To illustrate the overall resource allocation process, this application also provides a timing diagram for traffic scheduling based on the Internet of Vehicles (IoV). Figure 5 ).

[0097] like Figure 5 As shown, in a resource scheduling application scenario, the resource scheduling process can be generally divided into the following stages: I. Data Acquisition and Preprocessing Stage. The vehicle terminal sends traffic data to a traffic classifier, which categorizes the traffic data. Further, a feature extractor extracts features from the traffic data. The traffic data here corresponds to... Figure 2 The data requests for the in-vehicle applications described in the embodiments.

[0098] II. Intent Recognition Stage. The extracted multi-dimensional features are input into the communication demand recognition model to classify business scenarios and identify the communication needs (which can be understood as business intent) corresponding to the data.

[0099] III. Strategy Formulation Phase. Based on the identified business intent, a corresponding resource scheduling strategy is generated through the scheduling decision engine. Specifically, a resource allocation decision model is embedded in the scheduling decision engine, and the resource scheduling strategy is generated through this model.

[0100] IV. Strategy Execution Phase. Based on the resource scheduling strategy generated in the strategy phase, resource scheduling is executed.

[0101] V. Resource Allocation Adjustment. The overall resource allocation is adjusted through the resource executor. For example, a demand forecasting model can be embedded in the resource executor to determine changes in business needs, thereby adjusting resource allocation.

[0102] It should be noted that the stages in the resource scheduling process described above are merely an example. Traffic data can also be classified without using a traffic classifier. This application does not impose specific limitations on the stages in the resource scheduling process.

[0103] Exemplary vehicle-to-everything (V2X) traffic scheduling device The above text combined Figures 1-5 The method embodiments of this application have been described in detail above. The apparatus embodiments of this application are described in detail below. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be referred to the foregoing method embodiments. Figure 6 This is a schematic diagram of a traffic scheduling device based on the Internet of Vehicles, as shown in some embodiments of this application.

[0104] like Figure 6 As shown, the traffic scheduling device 600 based on the Internet of Vehicles (IoV) may include a data acquisition module 610, a demand identification module 620, a strategy formulation module 630, and a traffic allocation module 640. Among them, The data acquisition module 610 can be configured to: acquire network requests initiated by in-vehicle applications in real time, and acquire multi-dimensional context information corresponding to the network requests based on the network requests; The requirement identification module 620 can be configured to: identify the first communication requirement of the vehicle application based on multi-dimensional context information, wherein the first communication requirement is used to characterize the communication intent of the vehicle application; The strategy formulation module 630 can be configured to: dynamically generate a traffic allocation strategy for the first communication requirement in real time based on the first communication requirement; The traffic allocation module 640 can be configured to perform differentiated traffic allocation for in-vehicle applications based on a traffic allocation strategy.

[0105] In-vehicle applications can be software applications integrated into a vehicle to provide specific functions, services, or experiences for occupants (drivers and passengers). For example, in-vehicle applications may include one or more combinations of smart mobility service applications, cockpit information and entertainment applications, and vehicle remote service and status management applications. A network request can be an interaction process initiated by an in-vehicle application to a target (e.g., a cloud service platform) to obtain a specific function or service response.

[0106] In some embodiments, the demand identification module 620 can also be configured to classify in-vehicle applications deployed in the vehicle into vehicle-to-everything (V2X) applications and non-V2X applications based on the core functions and communication modes of the in-vehicle applications.

[0107] Multi-dimensional contextual information can be a collection of multiple data points used to characterize the current network state and the network request status of in-vehicle applications. For example, multi-dimensional contextual information may include at least one of vehicle status information, communication link information, user interaction information, and in-vehicle application information.

[0108] Specifically, multi-dimensional contextual information can include user behavior information, vehicle status information, network request information, network status information, and application information. User behavior information can include user identity information and user-performed vehicle operations (e.g., activated in-vehicle applications). Vehicle status data can include vehicle CAN bus data (e.g., vehicle speed, acceleration, braking status, turn signal status, tire pressure, etc.) and environmental perception data, such as geographic location information (GPS coordinates), weather conditions, road type, and current traffic conditions. Network request information includes the target domain name or IP address (e.g., map service API, entertainment server, etc.), protocol type (e.g., Message Queuing Telemetry Transport (MQTT) protocol, gRPC protocol), and the size and frequency of the sent message. Network status information can include the strength of the received signal in real time, network type, end-to-end latency, network jitter, and packet loss rate. Application information can include the application ID, process name, and digital signature (used to identify whether the requesting application is a trusted and secure application) of the in-vehicle application sending the request.

[0109] In some embodiments, the vehicle terminal may periodically report its status information, including vehicle status information and network status information, to the target (e.g., a cloud service platform). For example, a timer may be set in the vehicle system so that the vehicle system automatically triggers an information report each time a preset period is reached.

[0110] In some embodiments, the target end (e.g., a cloud service platform) may also proactively initiate a status information query request to the vehicle terminal based on management or service needs.

[0111] As an example, the first communication requirement may include the service type of the network request corresponding to the service, and the service intent determined according to the service type. For example, the communication requirement for an emergency braking request automatically sent by the in-vehicle application to surrounding vehicles before a collision may include: service type: emergency braking, service intent: safety warning; the communication requirement for a user's request to remotely unlock the car door via a mobile terminal may include: service type: interaction, service intent: remote interactive control; the communication requirement for a passenger's video or music playback request clicked on the in-vehicle screen may include: service type: in-vehicle service, service intent: entertainment.

[0112] As an example, the first communication requirement can include business type and business scenario. The importance and urgency of network requests can be determined based on the business type and scenario. Based on these differences, network requests can be categorized into critical business requests and non-critical business requests. Specifically, business requests directly related to vehicle driving safety and user safety, such as those related to vehicle safety systems, emergency call services, navigation, and driver assistance functions, can be classified as critical business requests. Business requests primarily used for entertainment and not directly affecting vehicle operation, such as music streaming and video streaming, can be classified as non-critical business requests.

[0113] As an example, the first communication requirement can include service type and priority level. Specifically, the latency requirement (which can be understood as urgency) of the service can be determined based on its service type, and the priority level of the service can be determined according to the different latency requirements. For example, network requests for services with high latency requirements (e.g., response latency requirement within 10ms) can be marked as high priority; network requests for services with moderate latency requirements (e.g., response latency requirement between 10ms and 100ms) can be marked as medium priority; and network requests for services with low latency requirements (e.g., greater than 100ms) can be marked as low priority. For example, network requests for advanced autonomous driving and emergency braking can be marked as high priority; network requests for real-time navigation can be marked as medium priority; and network requests for vehicle monitoring or in-vehicle entertainment can be marked as low priority. This allows for a more granular classification of network requests, providing more accurate basic data for subsequent resource allocation.

[0114] As an example, the first communication requirement can include service type, service scenario, and priority level. Considering that in practical applications, the urgency of the same type of service may change in different service scenarios—that is, services of the same type may be marked with different priority levels depending on the service scenario—the service scenario is added to the criteria for determining the priority level. Specifically, when the vehicle is traveling at high speed, video service requests are considered a risk of driver distraction and are marked as low priority; while when the vehicle is charging or waiting in a parked state, the same video service request is considered passenger entertainment and can be assigned medium priority.

[0115] By integrating multi-dimensional contextual information for comprehensive analysis, the communication requirements of in-vehicle applications are identified. Cross-validation from multiple dimensions significantly improves the accuracy of communication requirement identification. Furthermore, the identification results contain rich contextual semantic information, providing semantically understood decision-making basis for subsequent resource allocation decisions, thus making the final resource allocation decision more aligned with business logic.

[0116] In some embodiments, the requirement identification module 620 can also be configured to identify the first communication requirement of the vehicle application based on multi-dimensional context information and a communication requirement identification model.

[0117] For example, the communication demand identification model can be a deep learning-based network model, such as a convolutional neural network (CNN), a long short-term memory network (LSTM), or a Transformer time series model. For instance, CNN can be used to process time series network data, while LSTM or Transformer time series models can be used to process continuous vehicle state sequences.

[0118] In some embodiments, the multi-dimensional context information associated with the network request is input into the communication requirement identification network to obtain the communication requirement corresponding to the network request, such as the service type, service scenario and priority level of the network request.

[0119] Considering that the network requests of different in-vehicle applications have different service requirements (communication requirements) and urgency levels, in order to meet the diverse needs of in-vehicle applications, in some embodiments, an allocation strategy is dynamically generated based on the communication requirements of the network requests of the in-vehicle applications and the current network status, so as to achieve differentiated traffic allocation for different in-vehicle applications.

[0120] In some embodiments, the strategy formulation module may also be configured to adaptively generate a traffic allocation strategy for the first communication requirement based on the first communication requirement obtained in the aforementioned S220 through a resource allocation decision model.

[0121] In some embodiments, the resource allocation decision model can be a deep reinforcement learning model. The deep reinforcement learning model can be trained using historical decision information as training samples, enabling it to learn the mapping relationship between communication demands and traffic allocation strategies. Specifically, the state space of the deep reinforcement learning model can include historical allocation information of in-vehicle applications, specifically including historical multi-dimensional contextual information of the in-vehicle applications, communication demands, network state information, and allocation strategies (e.g., historical base station connection information, historical resource allocation information, historical data rates, and historical channel gains). The action space can include historical allocation strategies (e.g., decision information on historical base station resource allocation in the in-vehicle system).

[0122] For example, training samples can be used to enable the resource allocation decision model to learn the mapping relationship between communication requirements and traffic allocation strategies. Finally, the communication requirements of the network requests of the vehicle application are input into the resource allocation decision model. The resource allocation decision model outputs a traffic allocation strategy for the communication requirements based on the learned mapping relationship between communication requirements and traffic allocation.

[0123] In some embodiments, the policy formulation module 630 can also be configured to determine the number of currently active in-vehicle applications based on network requests initiated by in-vehicle applications. Based on the number and a first communication requirement, a second communication requirement for the vehicle is predicted using a demand prediction model. The second communication requirement represents the communication needs of the vehicle during subsequent driving, i.e., potential future communication needs. Data related to the second communication requirement is pre-loaded, and the traffic allocation strategy is adjusted according to the second communication requirement.

[0124] It should be understood that specific limitations regarding the apparatus can be found in the limitations regarding the method described above, and will not be repeated here. Each module in the aforementioned apparatus can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in a computer device, or stored in software in the memory of a computer device, so that the processor can call and execute the operations corresponding to each module.

[0125] Exemplary electronic devices and computer-readable storage media This application also provides an electronic device, such as Figure 7 As shown. The electronic device 700 provided in this application includes a memory 710, a processor 720, and an input / output interface 630. The memory 710, processor 720, and input / output interface 730 are connected via internal connection paths. The memory 710 stores instructions, and the processor 720 executes the instructions stored in the memory 710 to control the input / output interface 630 to receive input data and information, and output operation results and other data.

[0126] It should be understood that in the embodiments of this application, the processor 720 may be a general-purpose central processing unit (CPU), GPU, FPGA, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute related programs in order to implement the technical solutions provided in the embodiments of this application.

[0127] The memory 710 may include read-only memory and random access memory, and provides instructions and data to the processor 720. A portion of the processor 720 may also include non-volatile random access memory. For example, the processor 720 may also store device type information.

[0128] In implementation, each step of the above method can be completed by the integrated logic circuits in the hardware of the processor 720 or by instructions in software form. The vehicle-to-everything (V2X) traffic scheduling method disclosed in this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in 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 710, and the processor 720 reads the information in memory 710 and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here. This application also provides a computer program product, including a computer program / instructions. When the computer program / instruction processor in the computer program product provided in this application is executed, the vehicle-to-everything (V2X) traffic scheduling method provided in this application can be implemented.

[0129] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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 the prior art, 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 verification codes, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0136] It should be noted that in the description of this application, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0137] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications or equivalent substitutions made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A traffic scheduling method based on vehicle-to-everything (V2X) networks, applied to a V2X-based traffic scheduling system, the method comprising: Real-time acquisition of network requests initiated by in-vehicle applications within the vehicle, and acquisition of multi-dimensional context information based on the network requests; Based on the multi-dimensional context information, the first communication requirement of the in-vehicle application is identified, wherein the first communication requirement is used to characterize the communication intent of the in-vehicle application to initiate the network request; Based on the first communication requirement, a traffic allocation strategy is dynamically generated in real time for the first communication requirement. Based on the traffic allocation strategy, differentiated traffic allocation is performed for the in-vehicle application.

2. The traffic scheduling method based on vehicle-to-everything (V2X) communication according to claim 1, characterized in that, The step of identifying the current first communication requirement of the in-vehicle application based on the multi-dimensional context information includes: The semantic information contained in the multi-dimensional context information is extracted by the communication requirement identification model, and the first communication requirement of the vehicle application is identified based on the semantic information.

3. The traffic scheduling method based on vehicle-to-everything (V2X) communication according to claim 1, characterized in that, The step of dynamically generating a traffic allocation strategy for the first communication requirement in real time includes: Based on the first communication requirement, the priority level of the first communication requirement is evaluated through a resource allocation decision model, and a traffic allocation strategy for the first communication requirement is determined based on the priority level.

4. The traffic scheduling method based on the Internet of Vehicles according to claim 3, characterized in that, The method further includes: The identified first communication requirement and the generated traffic allocation strategy are used as new training samples to train the resource allocation decision model, thereby optimizing the resource allocation decision model.

5. The traffic scheduling method based on vehicle-to-everything (V2X) communication according to claim 1, characterized in that, The method further includes: A mapping table is pre-set to characterize the mapping relationship between the service type of the vehicle and the service quality agreement grading standard; The step of dynamically generating a traffic allocation strategy for the first communication requirement in real time includes: Based on the mapping table, determine the priority level of the first communication request; Based on the priority level, a traffic allocation strategy corresponding to the first communication requirement is generated.

6. The traffic scheduling method based on vehicle-to-everything (V2X) communication according to claim 1, characterized in that, The method further includes: The number of currently active in-vehicle applications is determined based on the network requests initiated by the in-vehicle applications within the vehicle. Based on the quantity and the first communication requirement, the second communication requirement of the vehicle is predicted by the mapping relationship between the multi-dimensional context information and the change in communication requirement learned by the demand prediction model, wherein the second communication requirement is the communication requirement of the vehicle in the subsequent driving process. Data related to the second communication requirement is preloaded, and the traffic allocation strategy is adjusted according to the second communication requirement.

7. The traffic scheduling method based on vehicle-to-everything (V2X) network according to any one of claims 1 to 6, characterized in that, The first communication requirement includes at least one of the service type and service scenario of the service corresponding to the network request, and the multi-dimensional context information includes at least one of the vehicle status information, communication link status information, user interaction information, and vehicle application information.

8. The traffic scheduling method based on vehicle-to-everything (V2X) communication according to any one of claims 1 to 6, characterized in that, The vehicle-to-everything (V2X) traffic scheduling system includes a cloud service platform, in which control components and microservice components provided by a service mesh are deployed. The step of identifying the current first communication requirement of the in-vehicle application based on the multi-dimensional context information includes: Based on the multi-dimensional context information, the first communication requirement of the in-vehicle application is identified through the microservice component; The step of dynamically generating a traffic allocation strategy for the first communication requirement in real time includes: Based on the first communication requirement, the microservice component dynamically generates a traffic allocation strategy for the first communication requirement in real time to achieve dynamic traffic allocation. The step of allocating differentiated traffic to the in-vehicle application according to the traffic allocation strategy includes: According to the traffic allocation strategy, the control component performs differentiated traffic allocation for the in-vehicle application.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program for executing the traffic scheduling method based on the Internet of Vehicles as described in any one of claims 1 to 8.

10. A vehicle, characterized in that, The vehicles include: processor; Memory used to store the processor's executable instructions. The processor is used to execute the traffic scheduling method based on the Internet of Vehicles as described in any one of claims 1 to 8.

Images