Network management method of vehicle, vehicle, electronic device, and storage medium

Abstract

The embodiment of the specification provides a network management method of a vehicle, relates to the technical field of Internet of Vehicles, and comprises the following steps: network data packets from the vehicle are acquired, and private service data packets are determined; then, service identification is performed on the network data packets based on traffic feature recognition rules configured by network addresses, so as to distinguish vehicle service traffic and user service traffic; the vehicle service traffic and the user service traffic are routed to different public network access points respectively, and a public network access point routing relationship different from that of the user service traffic is established for the private service data packets; and network data transmission is performed according to the public network access points and the routing relationship configuration. Therefore, automatic distinction and differential routing of the vehicle service traffic and the user service traffic are realized, the vehicle service traffic is separated from the user payment channel, the operation cost is reduced, and the rationality of channel resource utilization is improved.

Description

Technical Field

[0001] This specification relates to the field of vehicle networking technology, specifically to vehicle network management technology in the field of vehicle networking technology, and more specifically, to a vehicle network management method, vehicle, electronic device and storage medium. Background Technology

[0002] With the development of vehicle-to-everything (V2X) technology, in-vehicle communication modules need to handle increasingly diverse communication services, including safety command interaction between the vehicle and the control platform, user traffic for entertainment information services, and big data backhaul generated by intelligent driving.

[0003] To meet the different requirements of various services for network bandwidth, latency, security and cost, multiple access points are usually integrated in the vehicle communication module to separate traffic.

[0004] However, as business volume increases, the sources of traffic corresponding to access points become increasingly complex. For example, the traffic generated by the vehicle system includes not only entertainment traffic used by users (such as online music and video), but also traffic from company services such as vehicle system updates and map data downloads. This causes traffic congestion at some access points, which cannot be traced and managed. Meanwhile, some access points are idle due to business reasons, resulting in low utilization and wasting network resources. Summary of the Invention

[0005] This specification provides a vehicle network management method, a vehicle, electronic devices, and a storage medium to improve the utilization rate of vehicle network access points.

[0006] To achieve the above technical objectives, the embodiments of this specification provide the following technical solutions: Firstly, one embodiment of this specification provides a network management method for a vehicle, comprising: Obtain network data packets from the vehicle and determine the private service data packets associated with the vehicle communication module; The network data packets are identified according to traffic feature recognition rules to determine the traffic type corresponding to the network data packets. The traffic type includes vehicle service traffic and user service traffic. The traffic feature recognition rules are configured based on network addresses, and the network addresses are used to indicate the service affiliation of the traffic. The user service traffic and the vehicle service traffic are routed to different public network access points, and a routing relationship between the private service data packets and the public network access points is established. The public network access point indicated by the routing relationship is different from the public network access point of the user service traffic. Based on the configuration of the public network access point and the routing relationship, the network data transmission process of the vehicle is supported, and the network data transmission process is associated with the network data packets and the private service data packets.

[0007] Optionally, in one possible implementation, the step of performing service identification on the network data packets according to traffic feature identification rules to determine the traffic type corresponding to the network data packets includes: Send a request for traffic feature identification rules to the cloud platform associated with the vehicle communication module, so that the cloud platform can traverse the vehicle service items and obtain an address list based on the address information of the vehicle service items; Obtain the list of addresses sent by the cloud platform; Based on the address list, address matching is performed with the network data packets. The traffic type of the matched items is marked as vehicle service traffic, and the traffic type of other items is marked as user service traffic.

[0008] In this implementation, the vehicle communication module sends a request for traffic feature identification rules to the cloud platform. The cloud platform then traverses the vehicle service items and generates an address list based on the service addresses, achieving real-time synchronization between the identification rules and the cloud service catalog. This avoids the problem of newly launched services not being correctly identified due to the solidification of local rules. After obtaining the address list issued by the cloud platform, it is matched with network data packets. Successful matches are marked as vehicle service traffic, while unmatched matches are marked as user business traffic. This achieves a dynamically updated traffic classification mechanism that does not require all service information to be pre-installed on the terminal, improving the accuracy of traffic identification and the convenience of rule maintenance.

[0009] Optionally, in one possible implementation, routing the user service traffic and the vehicle service traffic to different public network access points, and establishing the routing relationship between the private service data packets and the public network access points, includes: Identify the primary access point for providing public network services and the secondary access point for providing intelligent driving services; The user service traffic is routed to the first access point, and the vehicle service traffic is routed to the second access point; Establish the routing relationship between the private service data packets and the second access point.

[0010] In this implementation, by identifying the first access point providing public network services and the second access point providing intelligent driving services, the functional positioning of different access points is clarified, providing a clear anchor point for subsequent traffic splitting. By routing user service traffic to the first access point and vehicle service traffic to the second access point, the physical separation of user personal services and vehicle system services in the transmission channel is achieved, avoiding the vehicle service traffic crowding out the bandwidth resources of the user's payment channel. At the same time, a routing relationship is established between the private service data packets and the second access point, so that the service data generated by the vehicle communication module itself and the vehicle service traffic share the same enterprise-side channel, realizing the unified bearing of enterprise services, improving channel utilization and simplifying cost accounting.

[0011] Optionally, in one possible implementation, establishing the routing relationship between the private service data packet and the second access point includes: Determine the load information of the second access point after it accesses the vehicle service traffic; Obtain the requirement information corresponding to the private service data packet; If the load information indicates that the second access point meets the requirement information, then a routing relationship between the private service data packet and the second access point is established.

[0012] In this implementation, before establishing the routing relationship between the private service data packet and the second access point, the current load information of the second access point after accessing the vehicle service traffic is determined, and the transmission requirements corresponding to the private service data packet are obtained, thereby realizing real-time assessment of the remaining carrying capacity of the access point. The routing relationship is only established when the load information is determined to meet the transmission requirements, thereby realizing dynamic access control based on the actual network conditions. This avoids forcibly injecting large traffic of private services when the access point is under high load, which could cause congestion and improve the stability of data transmission and the overall utilization efficiency of access point resources.

[0013] Optionally, in one possible implementation, the configuration process for the routing relationship includes: Send a login message to the cloud platform. The login message carries a capability bit, which is used to indicate whether the vehicle communication module supports transmitting private service data packets over the public network. When the capability bit indication supports it, the system receives public network collection configuration information issued by the cloud platform. The public network collection configuration information includes a transmission switch, a public network access point identifier, and a public network service port number. When the transmission switch is in the ON state, a secure connection is established with the public network service cluster of the cloud platform through the public network access point indicated by the public network access point identifier and the public network service port number, and the private business data packet is transmitted through the secure connection.

[0014] In this implementation, a login message carrying capability bits is sent to the cloud platform. These capability bits indicate whether the vehicle communication module supports transmitting private service data packets over the public network. This enables the terminal to declare its capabilities to the cloud, allowing the cloud platform to differentiate between different device versions and implement differentiated strategies. When the capability bits indicate support, the module receives public network collection configuration information from the cloud platform, including the transmission switch, public network access point identifier, and service port number. This enables dynamic switching of the transmission channel for high-volume private services from the private network to the public network, avoiding continuous occupation of private network bandwidth and expansion costs. When the transmission switch is on, a secure connection is established with the public network service cluster through the specified access point and port according to the configuration, and data is transmitted. This achieves a traffic scheduling mechanism with unified cloud management and on-demand execution by the terminal, improving the flexibility of high-volume service transmission and system scalability.

[0015] Optionally, in one possible implementation, the method further includes: When the capability bit indication is not supported, receive the shutdown command sent by the cloud platform; In response to the shutdown command, the private service data packets are maintained to be transmitted through the private network access point.

[0016] In this implementation, when the capability bit reported by the vehicle communication module does not support public network transmission capability, it receives a shutdown command sent by the cloud platform instead of collecting configuration from the public network. This enables the cloud to accurately identify and differentiate unsupported devices. In response to the shutdown command, it maintains the transmission of private business data packets through the private network access point, thus achieving uninterrupted maintenance of the communication logic of existing devices. This ensures that the business continuity of unupgraded or outdated vehicle communication modules is not affected by the deployment of new functions, achieving the effect of smooth and controllable promotion of new functions in a large number of existing vehicles and reducing the risk of business interruption during the upgrade process.

[0017] Optionally, in one possible implementation, the login message further includes vehicle model information, which is used to instruct the cloud platform to determine the firmware version information corresponding to the vehicle. The method further includes: Receive firmware prompt information sent by the cloud platform based on the vehicle model information, wherein the firmware prompt information is determined based on the matching of the function configuration parameters indicated by the firmware version information with the capability bits; Based on the firmware prompt information, perform a firmware upgrade on the vehicle communication module.

[0018] In this implementation, by including vehicle model information in the login message, the cloud platform can identify the vehicle model and associate it with the corresponding firmware version information, thereby providing a further description of the device's capabilities. Then, it receives firmware prompt information generated by the cloud platform based on the vehicle model information and capability matching, enabling the vehicle communication module to understand the gap between its own firmware version and the current functional requirements. Based on the firmware prompt information, it performs a firmware upgrade operation, which proactively repairs the problem of mismatch between capability bits and actual firmware functions caused by configuration errors or outdated versions. This improves the coverage of terminals with public network data collection capabilities and increases the efficiency of large-scale activation of new functions.

[0019] Secondly, one embodiment of this specification provides a network management device for a vehicle, comprising: An acquisition unit is used to acquire network data packets from the vehicle and determine the private service data packets associated with the vehicle communication module; The management unit is used to identify the network data packets according to traffic feature identification rules to determine the traffic type corresponding to the network data packets. The traffic type includes vehicle service traffic and user service traffic. The traffic feature identification rules are configured based on network addresses, and the network addresses are used to indicate the service affiliation of the traffic. The management unit is also configured to route the user service traffic and the vehicle service traffic to different public network access points, and establish a routing relationship between the private service data packets and the public network access points, wherein the public network access point indicated by the routing relationship is different from the public network access point of the user service traffic; The management unit is also configured to support the network data transmission process of the vehicle based on the configuration of the public network access point and the routing relationship, wherein the network data transmission process is associated with the network data packets and the private service data packets.

[0020] Thirdly, one embodiment of this specification also provides a vehicle network management system, including sensors and a vehicle controller, wherein the sensors are used to collect vehicle-related data; and the vehicle controller is used to execute the vehicle network management method as described in the first aspect or any possible implementation thereof.

[0021] Fourthly, one embodiment of this specification also provides a vehicle, the vehicle comprising: a memory for storing executable program code; and a processor for calling and running the executable program code from the memory, causing the vehicle to perform the vehicle network management method in the first aspect or any possible implementation thereof.

[0022] Fifthly, one embodiment of this specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the vehicle network management method described above.

[0023] Sixthly, embodiments of this specification provide a computer program product or computer program, the computer program product including a computer program that can be stored in a computer-readable storage medium or in the cloud; the processor of the computer device reads the computer program, and when the processor executes the computer program, it implements the steps of the above-described vehicle network management method.

[0024] As can be seen from the above technical solutions, the vehicle network management method provided in this specification acquires network data packets from the vehicle, determines the private service data packets associated with them, and identifies the network data packets according to traffic feature identification rules configured based on network addresses. This accurately distinguishes the originally mixed data streams into vehicle service traffic and user service traffic, achieving precise determination of traffic service attribution and providing a basis for subsequent differentiated transmission and traceability management. Then, the identified user service traffic and vehicle service traffic are routed to different public network access points, achieving physical isolation between the two types of services on the transmission channel. This prevents user service traffic and vehicle system service traffic from competing for bandwidth, effectively alleviating the traffic congestion problem of a single access point. Simultaneously, by establishing a different routing relationship between the private service data packets and the public network access points used by the user service traffic, the service data generated by the vehicle communication module itself is integrated into an independent channel for transmission. This avoids exacerbating congestion due to private service data or vehicle service data crowding out the user service channel, and also allows network access points that were originally idle or underutilized to be effectively utilized, improving the overall network resource utilization and transmission balance. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this specification. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0026] Figure 1 This is a schematic diagram illustrating the application environment of a vehicle network management method provided as one embodiment of this specification.

[0027] Figure 2 This is a flowchart illustrating a vehicle network management method according to one embodiment of this specification.

[0028] Figure 3 This is a schematic diagram illustrating a scenario of a vehicle network management method provided as one embodiment of this specification.

[0029] Figure 4 This is a schematic diagram of a network terminal interaction scenario provided for one embodiment of this specification.

[0030] Figure 5 This is a schematic diagram of the functional modules of a vehicle network management device provided in one embodiment of this specification.

[0031] Figure 6 This is a structural schematic diagram of a vehicle provided for one embodiment of this specification. Detailed Implementation

[0032] Unless otherwise defined, the technical or scientific terms used in the embodiments of this specification shall have the ordinary meaning understood by one of ordinary skill in the art to which this specification pertains. The terms "first," "second," and similar terms used in the embodiments of this specification do not indicate any order, quantity, or importance, but are merely used to avoid confusion of constituent elements.

[0033] Unless the context otherwise requires, throughout this specification, "a plurality of" means "at least two," and "including" is interpreted as open-ended or encompassing, that is, "including, but not limited to." In the description of this specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this specification. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example.

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

[0035] With the development of vehicle-to-everything (V2X) technology, the Telematics Box (TBOX) needs to handle increasingly diverse communication services, including safe command interaction between the vehicle and the control platform, user traffic for entertainment information services, and big data backhaul generated by intelligent driving.

[0036] To meet the different requirements of various services for network bandwidth, latency, security and cost, multiple access point names (APNs) are usually integrated in a TBOX to separate traffic.

[0037] However, as business volume increases, the sources of traffic corresponding to access points become increasingly complex. For example, the traffic generated by the vehicle system includes not only entertainment traffic used by users (such as online music and video), but also traffic from company services such as vehicle system updates and map data downloads. This causes traffic congestion at some access points, which cannot be traced and managed. Meanwhile, some access points are idle due to business reasons, resulting in low utilization and wasting network resources.

[0038] To address the aforementioned issues, this specification provides a vehicle network management system, and the vehicle network management method provided in this specification is applied to the vehicle network management system. This management system achieves load balancing, cost optimization, and flexible expansion of multiple APN channels in the vehicle through an intelligent traffic scheduling strategy based on service identification and a public network data acquisition and switching mechanism that supports progressive adaptation.

[0039] Specifically, the vehicle's network management system may include... Figure 1 The operating environment formed by server 110 and vehicle 120 is described. Vehicle 120 communicates with server 110 via a network connection. The functions implemented within vehicle 120 can be local processing or information received by vehicle 120 and uploaded to cloud server 110, which then processes the information and sends it back to vehicle 120. Server 110 can be an electronic device with certain computing capabilities. It may have a network communication module, processor, and memory, etc. Of course, server 110 can also refer to software running on the electronic device. Server 110 can also be a distributed server, which can be a system with multiple processors, memory, network communication modules, etc., working together. Alternatively, server 110 can also be a cluster of several servers 110. Or, with the development of science and technology, server 110 can also be a new technical means capable of realizing the corresponding functions of the embodiments described in the specification. For example, it can be a new form of "server" based on quantum computing.

[0040] Specifically, when configuring the network within the vehicle, the aforementioned management system acquires network data packets from the vehicle and identifies their associated private service data packets. Based on traffic characteristic identification rules configured according to network addresses, it performs service identification on the network data packets, accurately distinguishing the originally mixed data streams into vehicle service traffic and user service traffic. This precise determination of traffic service attribution provides a basis for subsequent differentiated transmission and traceability management. The identified user service traffic and vehicle service traffic are then routed to different public network access points, achieving physical isolation between the two types of services on the transmission channel. This prevents user service traffic and vehicle system service traffic from competing for bandwidth, effectively alleviating traffic congestion problems at single access points. Simultaneously, by establishing a different routing relationship between the private service data packets and the public network access points used by user service traffic, the service data generated by the vehicle communication module itself is integrated into an independent channel for transmission. This avoids exacerbating congestion due to private service data or vehicle service data crowding out user service channels, and also allows previously idle or underutilized network access points to be effectively utilized, improving the overall network resource utilization and transmission balance.

[0041] Based on the above concept, this specification provides a vehicle network management method. The vehicle network management method provided in this specification will be described exemplarily below with reference to the accompanying drawings.

[0042] To be applied Figure 1 Taking a vehicle as an example, this specification provides illustrative examples of some implementation methods for the network management of such vehicles, such as... Figure 2 As shown, Figure 2 A flowchart illustrating a vehicle network management method according to one embodiment of this specification; the vehicle network management method includes: 201. Obtain network data packets from the vehicle and determine the private service data packets associated with the vehicle communication module.

[0043] In this embodiment, the vehicle communication module refers to a hardware unit or integrated component installed inside the vehicle to enable data communication between the vehicle and external networks. It can connect to the in-vehicle network, for example, communicating with in-vehicle nodes such as the vehicle infotainment system and domain controllers via in-vehicle Ethernet or Controller Area Network (CAN) bus. Network requests generated by the vehicle infotainment system when running various applications (such as online navigation, music, video, system upgrades, map updates, etc.) are aggregated to the vehicle communication module in the form of data packets. In this step, the vehicle communication module acquires these network data packets to be sent. Simultaneously, the vehicle communication module itself is also associated with proprietary service data packets, such as remote diagnostic data, national standard reporting data, full CAN acquisition files, log uploads, configuration downloads, etc., belonging to the vehicle manufacturer or service provider. These proprietary service data packets are generated by the vehicle communication module itself or specific in-vehicle sensors / controllers connected to it, and need to be transmitted externally via the network. Their service affiliation differs from entertainment traffic directly initiated by the vehicle infotainment system user.

[0044] As a specific implementation method, the vehicle communication module can distinguish between in-vehicle network requests and its own private service data packets through different logical interfaces or network sockets. For example, data packets from in-vehicle applications enter the forwarding plane of the vehicle communication module through a specified virtual network card or IP routing rules, while private service data packets are directly generated and injected into the forwarding plane by the local service process of the vehicle communication module, carrying specific service tags. This approach allows for data source labeling before data enters the triage decision-making stage, creating conditions for subsequent differentiated processing.

[0045] In this embodiment, network data packets refer to any data unit initiated by the vehicle's infotainment system or in-vehicle applications that needs to be transmitted over the public network. The service content they carry may include map tiles, system firmware, streaming media slices, web page requests, etc. Additionally, private service data packets refer to data generated by the enterprise's own services related to vehicle operation management, safety monitoring, and remote maintenance, such as CAN bus data acquisition, logs, and configuration uploads. These are typically triggered internally by the vehicle communication module and not actively initiated by the end user. It should be noted that the acquisition and differentiation of the above information provides a data foundation for differentiated routing based on service affiliation in subsequent steps, thereby jointly solving the cost confusion and channel abuse problems caused by unclear traffic affiliation in related technologies.

[0046] 202. Based on the traffic feature identification rules, perform service identification on network data packets to determine the traffic type corresponding to the network data packets. The traffic type includes vehicle service traffic and user service traffic. The traffic feature identification rules are based on network address configuration, and the network address is used to indicate the service affiliation of the traffic.

[0047] In this embodiment, after acquiring network data packets, the vehicle communication module matches each or each group of network data packets using preset traffic feature identification rules. The core basis of these rules is the network address, such as an IP address, domain name, or URL pattern. The network address identifies the communication peer of the data packet, and the service attribute of that peer can reflect whether the data packet provides services to the vehicle (such as a system upgrade server) or provides entertainment content to the user (such as a video content delivery network). Therefore, rules based on network addresses can effectively determine the service affiliation of traffic.

[0048] Specifically, in-vehicle service traffic refers to data traffic provided by the vehicle manufacturer or service operator (also known as car company, etc.) that is not directly aimed at users' entertainment consumption, such as over-the-air firmware upgrade packages, online map updates, vehicle health report uploads, and other services that support vehicle function modules.

[0049] In addition, user service traffic refers to data traffic initiated by vehicle users and typically paid for by them, such as online audio and video playback, web browsing, and interaction with third-party applications. The address-based classification described above enables refined management of in-vehicle traffic, separating in-vehicle service traffic that was previously mixed in with the user-paid channels. This reduces the traffic costs borne by enterprises for their own business and purifies the user service channel.

[0050] In one possible scenario, considering that the fixed traffic identification rules pre-set locally by the vehicle communication module are difficult to keep synchronized with the cloud service catalog, when the cloud platform adds or changes vehicle service items, the local rules cannot be updated in time, which may lead to some vehicle service traffic being misjudged as user business traffic. Therefore, a method is adopted in which the vehicle communication module actively requests rules from the cloud platform, the cloud platform traverses the current service items to generate an address list and then distributes it, and the terminal performs address matching based on the dynamic list to achieve real-time alignment between the identification rules and the cloud service status.

[0051] Specifically, the process of determining traffic types can begin by sending a request for traffic feature identification rules to the cloud platform associated with the vehicle communication module. This allows the cloud platform to traverse vehicle service items and obtain an address list based on the address information of the vehicle service items. Then, the address list sent by the cloud platform is retrieved, and address matching is performed between the address list and network data packets. The traffic type of the matched items is marked as vehicle service traffic, while the traffic type of other items is marked as user service traffic.

[0052] The traffic feature identification rule refers to the matching strategy used by the in-vehicle communication module to determine the service affiliation of network data packets. This rule uses network addresses as the core identification basis. Specifically, the rule maintains a list of network addresses associated with in-vehicle system services. When the destination address of a network data packet matches the server address recorded in the list, the data packet is identified as in-vehicle service traffic; data packets that do not match are identified as user service traffic. Through this rule, the in-vehicle communication module can automatically classify mixed traffic within the vehicle at the data forwarding level, providing a basis for subsequent decision-making on routing different types of traffic to different public network access points.

[0053] For example, after TBOX starts connecting to the network, it sends a request message to the cloud platform to obtain the latest traffic identification rules. Upon receiving the request, the cloud platform queries the current service directory for all in-vehicle services, such as system upgrades, map updates, and remote diagnostics, extracts the server IP addresses or domain names of each service, and compiles them into an address list for distribution. TBOX receives this address list and stores it locally. When the in-vehicle entertainment system initiates a new HTTP request, TBOX parses the target IP address of the request, compares it line by line in the address list, and if it finds that the IP matches a record for a map update server, it marks this data stream as in-vehicle service traffic.

[0054] As can be seen, this embodiment sends a request for traffic feature identification rules to the cloud platform through the vehicle communication module. The cloud platform then traverses the vehicle service items and generates an address list based on the service addresses, achieving real-time synchronization between the identification rules and the cloud service catalog. This avoids the problem of newly launched services not being correctly identified due to the solidification of local rules. After obtaining the address list issued by the cloud platform, it matches the addresses with network data packets. Successful matches are marked as vehicle service traffic, and unmatched matches are marked as user business traffic. This achieves a dynamically updated traffic classification mechanism that does not require the terminal to pre-install all service information, improving the accuracy of traffic identification and the convenience of rule maintenance.

[0055] 203. Route user service traffic and vehicle service traffic to different public network access points, and establish a routing relationship between private service data packets and public network access points. The public network access point indicated by the routing relationship is different from the public network access point of the user service traffic.

[0056] In this embodiment, a public network access point refers to a logical identifier in a mobile communication network that provides a connection point for terminal devices to a public data network (such as the Internet). It is typically defined and distinguished by the access point name. In a vehicle-to-everything (V2X) scenario, the vehicle communication module establishes packet data links through different public network access points. Each public network access point corresponds to an independent transmission channel, with its own network address allocation, quality of service (QoS) policy, and billing attribution. Different public network access points can be used to carry different types of service traffic. For example, user entertainment traffic and vehicle system service traffic can be allocated to different public network access points to achieve transmission isolation and independent billing between services.

[0057] Furthermore, routing relationships refer to a data forwarding rule or mapping binding established within the vehicle communication module. This rule specifies which network access point a particular type of data packet should be sent out through. This relationship clarifies the correspondence between the classification characteristics of data packets and the transmission channel. For example, data packets originating from vehicle system services are bound to one public network access point, while user entertainment data packets are bound to another. When sending data, the vehicle communication module uses the configured routing relationship to find the matching access point and sends the data packet from the corresponding network interface, thereby achieving targeted distribution and transmission control of different service traffic.

[0058] In one possible scenario, since in-vehicle service traffic and private service data packets both belong to the vehicle management entity (automobile manufacturer) and can be jointly managed, the public network access point indicated by the routing relationship and the public network access point indicated by the in-vehicle service traffic can use the same access point. That is, in the existing access point architecture, there is a private network access point APN1, a public network access point APN2, and a public network access point APN3 for intelligent driving data. Since intelligent driving data is periodic (i.e., there are non-intelligent driving periods) and also belongs to the vehicle management entity, APN3 can be used as the vehicle management entity's reused management interface. Specifically, first, the first access point (APN2) providing public network services and the second access point (APN3) providing intelligent driving services are determined; then, user service traffic is routed to the first access point, and in-vehicle service traffic is routed to the second access point; and a routing relationship is established between the private service data packets and the second access point.

[0059] For example, the vehicle is equipped with two public network access points, APN2 and APN3. APN2 is designated as the public network service channel carrying user entertainment applications, while APN3 is designated as the channel carrying in-vehicle systems and intelligent driving-related services. After completing traffic identification, the TBOX binds the traffic generated by users watching online videos to APN2 for transmission; and binds the traffic generated by the in-vehicle system downloading firmware packages to APN3 for transmission. Simultaneously, a full CAN data file generated by the TBOX itself is also established in the routing rules for APN3, ready for upload via APN3.

[0060] As can be seen, this embodiment clarifies the functional positioning of different access points by identifying a first access point providing public network services and a second access point providing intelligent driving services, thus providing a clear anchor point for subsequent traffic splitting. By routing user service traffic to the first access point and vehicle service traffic to the second access point, the physical separation of user personal services and vehicle system services in the transmission channel is achieved, avoiding the vehicle service traffic from crowding out the bandwidth resources of the user's payment channel. At the same time, a routing relationship is established between the private service data packets and the second access point, so that the service data generated by the TBOX itself and the vehicle service traffic share the same enterprise-side channel, realizing the unified bearing of enterprise services, improving channel utilization and simplifying cost accounting.

[0061] In one possible scenario, considering that the transmission of private service data packets may occur when the second access point is already carrying vehicle service traffic, directly establishing a routing relationship without considering the current load status could inject large amounts of data during high load periods, causing congestion and affecting the transmission quality of existing services. Therefore, before establishing a routing relationship, it is necessary to determine whether the access point's load meets the transmission requirements of the private service, and only confirm the establishment if the condition is met, thus achieving dynamic admission control of the access point. Therefore, for establishing a routing relationship, the load information of the second access point after receiving vehicle service traffic can be determined first; then, the demand information corresponding to the private service data packets can be obtained; if the load information indicates that the second access point meets the demand information, then the routing relationship between the private service data packets and the second access point can be established.

[0062] For example, TBOX prepares to upload a 2GB CAN acquisition file via APN3. Previously, APN3 was transmitting an onboard system upgrade package, with a current bandwidth utilization of approximately 40%. TBOX reads the continuous bandwidth requirement for this file upload and compares it with APN3's currently available bandwidth. The calculation shows that APN3's remaining bandwidth meets the minimum upload rate requirement, so TBOX confirms that the CAN file route should be directed to APN3 and begins transmission. If the remaining bandwidth is insufficient, TBOX will either postpone route establishment or wait for APN3 to become less busy before proceeding with transmission.

[0063] As can be seen, this embodiment determines the current load information of the second access point after it accesses the vehicle service traffic and obtains the transmission requirements corresponding to the private service data packets before establishing the routing relationship between the private service data packets and the second access point. This enables real-time assessment of the remaining carrying capacity of the access point. The routing relationship is only established when the load information is determined to meet the transmission requirements. This achieves dynamic access control based on the actual network conditions, avoids forcibly injecting large traffic of private services when the access point is under high load, which could cause congestion, and improves the stability of data transmission and the overall utilization efficiency of access point resources.

[0064] It should be noted that in the public network data collection scheme, the public network access point specified in the public network data collection configuration information issued by the cloud platform is not limited to a specific single access point. Its default configuration can point to the second public network access point, or it can be dynamically designated as the first access point according to the actual network deployment strategy. This design means that the transmission channel for high-volume private business data is no longer bound to a fixed access point, but is flexibly assigned by the cloud based on factors such as the current load status, pricing strategy, or business priority of each access point, realizing dynamic configurability of link selection.

[0065] Furthermore, when the vehicle network architecture is subsequently expanded to include new public network access points, such as a fourth access point added in the future, the cloud platform only needs to update the public network access point identifier in the configuration information to route private service data streams to the new channel, without requiring firmware upgrades or hardware modifications to the vehicle communication module. This mechanism supports continuous optimization of network resources and smooth expansion of access points, enabling link selection strategies to continuously adapt as the network evolves, further enhancing the overall flexibility and scalability of the system.

[0066] 204. Based on the configuration of public network access points and routing relationships, it supports the network data transmission process of vehicles. The network data transmission process is associated with network data packets and private service data packets.

[0067] In this embodiment, after completing the routing table entries and interface bindings, the vehicle communication module forms a stable multi-channel transmission configuration. During vehicle operation, regardless of whether the vehicle's infotainment system generates user entertainment traffic, triggers system upgrades to generate vehicle service traffic, or generates private service data packets triggered by a timer (such as periodic CAN acquisition), the vehicle communication module automatically selects a public network access point for transmission according to the configured rules. This process is transparent to upper-layer applications and requires no intervention from users or upper-layer applications. Therefore, vehicle network data transmission is optimized in terms of cost, load, and service isolation.

[0068] The network data transmission process refers to the concurrent transmission of classified network data packets and private service data packets by the vehicle communication module after completing traffic identification and routing configuration. Based on routing relationships, this process sends out vehicle service traffic and user service traffic through their respective bound public network access points, while simultaneously transmitting private service data packets through independent public network access points, thus enabling the orderly outgoing transmission of multiple types of data within the vehicle according to a traffic distribution strategy.

[0069] Based on the descriptions of the above embodiments, the access point management process of the vehicle communication module is as follows: Figure 3 As shown, Figure 3This diagram illustrates a scenario of a vehicle network management method provided in one embodiment of this specification. The diagram depicts the business processing flow of the TBOX system: Within the TBOX, through traffic identification, network requests from the vehicle's infotainment system are categorized into "company service traffic" (such as map updates, system upgrades, etc., i.e., in-vehicle service traffic) and "user entertainment traffic" (such as video playback, i.e., user service traffic) based on a preset IP address list. Data packets identified as company service traffic are routed to APN3 (the second access point), while user entertainment traffic is routed to APN2 (the third access point). Simultaneously, the TBOX's own public network services (including configuration downloads, log uploads, and full CAN file acquisition) are also automatically redirected from APN2 to APN3. Through IP address-based traffic identification and routing, refined management of vehicle infotainment system traffic is achieved. More importantly, all TBOX company services originally scattered across APN2 are integrated into APN3, achieving unified carrying and management of company service traffic, avoiding resource competition with user traffic, and allowing APN2 to function purely as a user payment channel, facilitating traffic management.

[0070] In one possible scenario, considering the inconsistent firmware version iteration progress of existing vehicles' TBOXes, directly distributing public network data collection configurations to all vehicles would prevent older devices that do not support this capability from parsing or executing the configuration, potentially causing communication anomalies. Therefore, a capability bit is set in the login message to declare whether the terminal supports public network transmission. Based on this, the cloud platform decides whether to distribute configuration information including a transmission switch, access point identifier, and service port number. The terminal then establishes a secure connection with the public network service cluster according to the configuration, enabling controllable and gradual deployment of new functions.

[0071] Based on this, the configuration process of routing relationships can begin by sending a login message to the cloud platform. The login message carries a capability bit, which indicates whether the vehicle communication module supports transmitting private service data packets over the public network. When the capability bit indicates support, the module receives public network collection configuration information from the cloud platform. This information includes a transmission switch, a public network access point identifier, and a public network service port number. When the transmission switch is on, a secure connection is established with the cloud platform's public network service cluster through the public network access point identifier and the public network service port number, and the private service data packets are transmitted through this secure connection.

[0072] For example, after a vehicle equipped with the new firmware starts up, the TBOX sends a login request to the cloud platform. The "public network acquisition capability bit" in the message is set to 1, indicating that it supports uploading CAN data via the public network. After verifying this capability bit, the cloud platform sends a configuration to the TBOX: the transmission switch is set to "on," the public network APN is specified as APN3, and the port number is 8088. After receiving and parsing the configuration, the TBOX enables APN3 as instructed and initiates a TLS handshake to port 8088 of the cloud platform's public network cluster, successfully establishing a secure connection. Subsequently, the TBOX continuously uploads periodically collected CAN data files through this TLS connection.

[0073] As can be seen, this embodiment sends a login message carrying capability bits to the cloud platform. The capability bits indicate whether the vehicle communication module supports transmitting private service data packets over the public network, realizing the terminal's capability status declaration to the cloud. This allows the cloud platform to distinguish between different versions of the device and implement differentiated strategies. When the capability bits indicate support, the device receives public network collection configuration information from the cloud platform, including the transmission switch, public network access point identifier, and service port number. This enables dynamic switching of the transmission channel for high-volume private services from the private network to the public network, avoiding continuous occupation of private network bandwidth and expansion costs. When the transmission switch is on, the device establishes a secure connection with the public network service cluster and transmits data according to the configuration through the specified access point and port. This realizes a traffic scheduling mechanism with unified cloud management and on-demand execution by the terminal, improving the flexibility of high-volume service transmission and system scalability.

[0074] Specifically, the interactive process for capability verification is as follows: Figure 4 As shown, Figure 4 This diagram illustrates a network terminal interaction scenario provided for one implementation of this specification. The diagram shows two stages of interaction between the TBOX and the cloud platform. The first stage is capability reporting and gradual adaptation: different vendors have different TBOX firmware version iteration rhythms. This solution solves this problem by designing a "support for public network reporting of high-volume services" capability bit in the login message. If vendor A has implemented this function in TBOX firmware v1.1, then its TBOX will set this capability bit to 1 (indicating support) upon login; vendor B's TBOX has not yet been upgraded, so it maintains this capability bit at 0 (indicating non-support). The cloud platform treats different scenarios based on the capability bit, only issuing public network collection configurations to TBOXes that support the new capability, while maintaining the original private network communication logic for those that do not support it, thus achieving a smooth and controllable deployment of the new function.

[0075] The second phase involves configuration distribution and connection establishment: After receiving a TBOX login request, the cloud platform verifies its capabilities. If supported, it distributes a configuration file to the TBOX, containing: a public network data collection and transmission switch (indicating whether this function is enabled), a public network link for high-traffic services (specifying which APN to use, defaulting to APN3), and a public network access port number for the TSP (specifying the port for connecting to the public network TSP cluster). After parsing the configuration, the TBOX, based on the switch status, will establish a new secure connection (such as TLS) with the cloud platform's public network service cluster for data transmission for the specified original private network high-traffic services (such as periodic CAN data collection) through the specified APN and port number.

[0076] As can be seen from the above interaction process, through capability awareness and dynamic configuration, high-traffic services are freed from the fixed private network APN1 and can be flexibly switched to the public network APN3 based on network conditions and cost considerations. This greatly alleviates the bandwidth pressure on the private network and leverages the abundant and cost-effective public network bandwidth resources, laying the foundation for the expansion of big data services. Its "capability bit" design also enables refined management of the large and heterogeneous existing and newly added vehicles. The platform can accurately identify and control which vehicles can enable new features, laying the foundation for batch-based, region-based OTA upgrades and service promotion.

[0077] Furthermore, considering that if the cloud platform still issues public network data collection configurations or performs channel switching when the capability bit reported by the vehicle communication module indicates that it does not support public network transmission capabilities, the module may experience communication interruption due to its inability to recognize the instructions. Therefore, the cloud platform sends a disable command to the unsupported capability bit. The terminal responds to this command by maintaining the transmission of private service data packets through the private network access point, thus ensuring uninterrupted maintenance of existing equipment and guaranteeing business continuity.

[0078] Therefore, when the capability bit indication does not support it, the system receives a shutdown command sent by the cloud platform (or the TBOX automatically generates a shutdown command after the cloud platform does not respond); then, in response to the shutdown command, it maintains the transmission of private service data packets through the private network access point.

[0079] For example, a TBOX in an existing vehicle has an older firmware version, and its login message has the "Public Network Data Acquisition Capability Bit" fixed at 0. After the cloud platform recognizes this bit as 0, it does not issue public network data acquisition configuration, but instead replies with an instruction to maintain the existing channel. Upon receiving this instruction, the TBOX does not make any changes to the current routing policy, and the CAN data acquisition continues to be uploaded to the enterprise's private platform through the existing private network APN1 channel. The entire process is completely consistent with that before the upgrade.

[0080] As can be seen, in this embodiment, when the capability bit indicated by the vehicle communication module does not support public network transmission capability, it receives a shutdown command sent by the cloud platform instead of collecting configuration from the public network. This enables the cloud to accurately identify and differentiate unsupported devices. In response to the shutdown command, it maintains the transmission of private business data packets through the private network access point, thus achieving uninterrupted maintenance of the communication logic of existing devices. This ensures that the business continuity of unupgraded or old TBOXes is not affected by the deployment of new functions, achieving the effect of smooth and controllable promotion of new functions in a large number of existing vehicles and reducing the risk of business interruption during the upgrade process.

[0081] Optionally, considering that relying solely on the capability bits reported by the vehicle communication module to determine functional support may lead to mismatches between capability bits and actual functions due to factory configuration errors or firmware version discrepancies, resulting in terminals with existing capabilities failing to enable new functions, vehicle model information is added to the login message. The cloud platform performs cross-validation based on the firmware version corresponding to the vehicle model and the capability bits, and issues firmware upgrade prompts to terminals with functional discrepancies, thereby achieving accurate assessment and proactive repair of terminal capabilities.

[0082] Based on this, vehicle model information can also be configured for login messages. The vehicle model information is used to instruct the cloud platform to determine the corresponding firmware version information for the vehicle. During the interaction between the TBOX and the cloud platform, firmware prompt information sent by the cloud platform based on the vehicle model information can be received. This firmware prompt information is determined based on the matching of the function configuration parameters and capability bits indicated by the firmware version information. Then, the firmware is upgraded for the vehicle communication module based on the firmware prompt information.

[0083] For example, a TBOX reports vehicle model "101" with a capability bit of 0 in its login message. The cloud platform searches its database based on vehicle model information and finds that the firmware pre-installed for this model actually supports public network data collection, but a configuration issue has caused the capability bit to be incorrectly set. The cloud platform sends a firmware notification to the TBOX, indicating the availability of an update to activate the public network data collection capability. Upon receiving the notification, the TBOX automatically downloads and flashes the new firmware while the vehicle is parked. After the upgrade is complete, the TBOX reports a capability bit of 1 upon its next login, and subsequently receives the public network data collection configuration from the cloud platform and enables the function.

[0084] As can be seen, this embodiment enables the cloud platform to identify the vehicle model and associate it with the corresponding firmware version information by carrying vehicle model information in the login message, thereby providing a further description of the device's capabilities. Receiving firmware prompts generated by the cloud platform based on the vehicle model information and capability matching allows the vehicle communication module to understand the gap between its firmware version and current functional requirements. Performing firmware upgrades based on these prompts proactively corrects mismatches between capability bits and actual firmware functions caused by configuration errors or outdated versions, improving the coverage of terminals with public network data collection capabilities and increasing the efficiency of large-scale activation of new functions.

[0085] As can be seen from the above embodiments, the following effects are achieved: (1) Cost optimization: A method for classifying and routing vehicle traffic to different APNs based on business feature identification. This enables refined management of vehicle traffic, separates company service traffic from user payment channels, and significantly reduces data traffic costs.

[0086] (2) Load balancing and resource optimization: The load balancing and service integration strategies of the original APN2 public network services of TBOX were adjusted to APN3 by default. The responsibilities of APN2 and APN3 were re-planned, and the corporate services on the original APN2 (especially the full CAN reporting of large traffic) were integrated into APN3, so that the network load was more balanced, the stability and efficiency of corporate service transmission were improved, and the APN2 channel was purified.

[0087] (3) System scalability and flexibility: Based on TBOX capability reporting and dynamic configuration distribution from the cloud platform, a mechanism is established to support the switching of private network services to public network links. Through the public network data collection scheme, high-volume services are no longer limited by private network bandwidth and can use more cost-effective public network resources on demand, supporting the unlimited expansion of future data services.

[0088] (4) Smooth upgrade and gradual adaptation: A capability bit is set in the login message, and the cloud platform decides whether to issue and execute the new strategy based on the capability bit. This is an interactive process to support gradual adaptation. Through the design of the "capability bit", the cloud platform can identify different versions of TBOX, realize the phased, controllable and gradual deployment of new functions in a large fleet, and greatly reduce the upgrade risk and coordination cost.

[0089] In summary, this embodiment acquires network data packets from vehicles, identifies their associated private service data packets, and performs service identification on the network data packets based on traffic feature recognition rules configured according to network addresses. This accurately distinguishes the originally mixed data streams into vehicle service traffic and user service traffic, achieving precise determination of traffic service attribution and providing a basis for subsequent differentiated transmission and traceability management. Then, the identified user service traffic and vehicle service traffic are routed to different public network access points, achieving physical isolation between the two types of services on the transmission channel. This prevents user service traffic and vehicle system service traffic from competing for bandwidth, effectively alleviating the traffic congestion problem of a single access point. Simultaneously, by establishing a different routing relationship between the private service data packets and the public network access points used by user service traffic, the service data generated by the vehicle communication module itself is integrated into an independent channel for transmission. This avoids exacerbating congestion due to private service data or vehicle service data crowding out user service channels, and also allows previously idle or underutilized network access points to be effectively utilized, improving the overall network resource utilization and transmission balance.

[0090] It should be noted that the various embodiments described in this specification emphasize the parts that differ from other embodiments, and the embodiments can be explained by comparison with each other. Any combination of the various embodiments described in this specification based on general technical knowledge is covered within the scope of this specification.

[0091] In one exemplary embodiment of this specification, a vehicle network management device 500 is also provided, such as... Figure 5 As shown, Figure 5 A functional module diagram of a vehicle network management device provided in one embodiment of this specification, the management device 500 including: The acquisition unit 501 is used to acquire network data packets from the vehicle and determine the private service data packets associated with the vehicle communication module. Management unit 502 is used to perform service identification on the network data packets according to traffic feature identification rules to determine the traffic type corresponding to the network data packets. The traffic type includes vehicle service traffic and user service traffic. The traffic feature identification rules are configured based on network addresses, and the network addresses are used to indicate the service affiliation of the traffic. The management unit 502 is further configured to route the user service traffic and the vehicle service traffic to different public network access points, and establish a routing relationship between the private service data packets and the public network access points, wherein the public network access point indicated by the routing relationship is different from the public network access point of the user service traffic; The management unit 502 is also used to support the network data transmission process of the vehicle based on the configuration of the public network access point and the routing relationship, wherein the network data transmission process is associated with the network data packet and the private service data packet.

[0092] Optionally, in one possible embodiment, the management unit 502 is specifically used to send a request for traffic feature identification rules to the cloud platform associated with the vehicle communication module, so that the cloud platform can traverse the vehicle service items and obtain an address list based on the address information of the vehicle service items. The management unit 502 is specifically used to obtain the address list sent by the cloud platform; The management unit 502 is specifically used to perform address matching based on the address list and the network data packets, mark the traffic type of the matched items as vehicle service traffic, and mark the traffic type of other items as user service traffic.

[0093] Optionally, in one possible embodiment, the management unit 502 is specifically used to determine a first access point that provides public network services and a second access point that provides intelligent driving services; The management unit 502 is specifically used to route the user service traffic to the first access point and the vehicle service traffic to the second access point; The management unit 502 is specifically used to establish the routing relationship between the private service data packet and the second access point.

[0094] Optionally, in one possible embodiment, the management unit 502 is specifically used to determine the load information of the second access point after it accesses the vehicle service traffic; The management unit 502 is specifically used to obtain the requirement information corresponding to the private business data packet; The management unit 502 is specifically used to establish a routing relationship between the private service data packet and the second access point if the load information indicates that the second access point meets the requirement information.

[0095] Optionally, in one possible embodiment, the management unit 502 is specifically used to send a login message to the cloud platform. The login message carries a capability bit, which is used to indicate whether the vehicle communication module supports transmitting private service data packets over the public network. The management unit 502 is specifically used to receive public network collection configuration information issued by the cloud platform when the capability bit indication supports it. The public network collection configuration information includes a transmission switch, a public network access point identifier, and a public network service port number. The management unit 502 is specifically used to establish a secure connection with the public network service cluster of the cloud platform through the public network access point indicated by the public network access point identifier and the public network service port number when the transmission switch is in the open state, and to transmit the private business data packet through the secure connection.

[0096] Optionally, in one possible embodiment, the management unit 502 is specifically configured to receive a shutdown command sent by the cloud platform when the capability bit indication does not support it; The management unit 502 is specifically used to respond to the shutdown command and maintain the transmission of the private service data packets through the private network access point.

[0097] Optionally, in one possible embodiment, the management unit 502 is specifically used to receive firmware prompt information sent by the cloud platform based on the vehicle model information, wherein the firmware prompt information is determined based on the matching of the function configuration parameters indicated by the firmware version information with the capability bits; The management unit 502 is specifically used to perform firmware upgrades on the vehicle communication module based on the firmware prompt information.

[0098] Specifically, in this embodiment, the acquisition unit and management unit can correspond to physical components. For example, the management unit can be a processing module such as a CPU, GPU, or FPGA, while the interaction unit can be an interaction module such as a screen, speaker, or projector. The specific physical component can be any component or combination of components with the above functions. The specific method depends on the actual scenario and is not limited here.

[0099] The aforementioned management device acquires network data packets from vehicles, identifies their associated private service data packets, and performs service identification on the network data packets based on traffic feature recognition rules configured according to network addresses. This accurately distinguishes the originally mixed data streams into vehicle service traffic and user service traffic, achieving precise determination of traffic service attribution and providing a basis for subsequent differentiated transmission and traceability management. The identified user service traffic and vehicle service traffic are then routed to different public network access points, achieving physical isolation between the two types of services on the transmission channel. This prevents user service traffic and vehicle system service traffic from competing for bandwidth, effectively alleviating the traffic congestion problem of a single access point. Simultaneously, by establishing a different routing relationship between the private service data packets and the public network access points used by user service traffic, the service data generated by the vehicle communication module itself is integrated into an independent channel for transmission. This avoids exacerbating congestion due to private service data or vehicle service data crowding out user service channels, and also allows previously idle or underutilized network access points to be effectively utilized, improving the overall network resource utilization and transmission balance.

[0100] Specific limitations regarding the vehicle's network management device can be found in the above section on vehicle network management methods, and will not be repeated here. Each unit module in the aforementioned vehicle network management device 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 corresponding operations of each module.

[0101] In addition, in one exemplary embodiment of this specification, a vehicle is also provided, such as Figure 6 As shown, Figure 6 This is a structural schematic diagram of a vehicle provided for one embodiment of this specification.

[0102] For example, vehicle 600 and Figure 1 Vehicle 120 in the text refers to the same vehicle.

[0103] For example, such as Figure 6 As shown, the vehicle 600 includes a memory 610 and a processor 620, wherein the memory 610 stores executable program code 630, and the processor 620 is used to call and execute the executable program code 630 to perform a method for network management of the vehicle.

[0104] For example, the memory 610 can be used to store related programs of the vehicle network management method provided in the embodiments of this application; the processor 620 can call the related programs of the vehicle network management method stored in the memory 610 to execute the vehicle network management method of the embodiments of this application; for example, obtaining network data packets from the vehicle and determining the private service data packets associated with the vehicle communication module; performing service identification on the network data packets according to traffic feature identification rules to determine the traffic type corresponding to the network data packets, the traffic type including vehicle service traffic and user service traffic, the traffic feature identification rules are configured based on network addresses, and the network address is used to indicate the service affiliation of the traffic; routing the user service traffic and vehicle service traffic to different public network access points, and establishing a routing relationship between the private service data packets and the public network access points, the public network access point indicated by the routing relationship is different from the public network access point of the user service traffic; based on the configuration of the public network access point and the routing relationship, supporting the network data transmission of the vehicle.

[0105] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0106] When each functional module is divided according to its corresponding function, the device may further include an acquisition module, a prediction module, a determination module, and an output module. It should be noted that all relevant content regarding the steps involved in the above method embodiments can be referenced to the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0107] It should be understood that the apparatus provided in this embodiment is used to execute the above-described vehicle network management method, and therefore can achieve the same effect as the above-described implementation method.

[0108] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing program code, etc.

[0109] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits as disclosed in this application. The processor may also be a combination of computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and microprocessors, etc., and the storage module may be a memory.

[0110] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a vehicle network management method provided in the above embodiments.

[0111] This application also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement the vehicle network management method provided in the above embodiments. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, Digital Video Discs (DVDs), Compact Disc Read-Only Memory (CD-ROMs), microdrives, and magneto-optical disks, read-only memory (ROMs), random access memory (RAMs), erasable programmable read-only memory (EPROMs), electrically erasable programmable read-only memory (EEPROMs), dynamic random access memory (DRAMs), video random access memory (VRAMs), flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and / or data.

[0112] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a vehicle network management method provided in the above embodiments.

[0113] The vehicle, computer-readable storage medium, computer program product or chip provided in this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0114] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0115] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or 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 device, 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 devices or units may be electrical, mechanical, or other forms.

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

[0117] The embodiments described above are merely illustrative of several implementation methods outlined in this specification. While the descriptions are specific and detailed, they should not be construed as limiting the scope of the solutions provided in this specification. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this specification, and these all fall within the scope of protection of this specification. Therefore, the scope of protection for this patent should be determined by the appended claims.

Claims

1. A network management method for vehicles, characterized in that, Applied to vehicle communication modules, the method includes: Obtain network data packets from the vehicle and determine the private service data packets associated with the vehicle communication module; The network data packets are identified according to traffic feature recognition rules to determine the traffic type corresponding to the network data packets. The traffic type includes vehicle service traffic and user service traffic. The traffic feature recognition rules are configured based on network addresses, and the network addresses are used to indicate the service affiliation of the traffic. The user service traffic and the vehicle service traffic are routed to different public network access points, and a routing relationship between the private service data packets and the public network access points is established. The public network access point indicated by the routing relationship is different from the public network access point of the user service traffic. Based on the configuration of the public network access point and the routing relationship, the network data transmission process of the vehicle is supported, and the network data transmission process is associated with the network data packets and the private service data packets.

2. The method according to claim 1, characterized in that, The step of identifying the network data packets according to traffic feature recognition rules to determine the traffic type corresponding to the network data packets includes: Send a request for traffic feature identification rules to the cloud platform associated with the vehicle communication module, so that the cloud platform can traverse the vehicle service items and obtain an address list based on the address information of the vehicle service items; Obtain the list of addresses sent by the cloud platform; Based on the address list, address matching is performed with the network data packets. The traffic type of the matched items is marked as vehicle service traffic, and the traffic type of other items is marked as user service traffic.

3. The method according to claim 1, characterized in that, The step of routing the user service traffic and the vehicle service traffic to different public network access points, and establishing the routing relationship between the private service data packets and the public network access points, includes: Identify the primary access point for providing public network services and the secondary access point for providing intelligent driving services; The user service traffic is routed to the first access point, and the vehicle service traffic is routed to the second access point; Establish the routing relationship between the private service data packets and the second access point.

4. The method according to claim 3, characterized in that, Establishing the routing relationship between the private service data packet and the second access point includes: Determine the load information of the second access point after it accesses the vehicle service traffic; Obtain the requirement information corresponding to the private service data packet; If the load information indicates that the second access point meets the requirement information, then a routing relationship between the private service data packet and the second access point is established.

5. The method according to claim 1, characterized in that, The configuration process for the routing relationship includes: Send a login message to the cloud platform. The login message carries a capability bit, which is used to indicate whether the vehicle communication module supports transmitting private service data packets over the public network. When the capability bit indication supports it, the system receives public network collection configuration information issued by the cloud platform. The public network collection configuration information includes a transmission switch, a public network access point identifier, and a public network service port number. When the transmission switch is in the ON state, a secure connection is established with the public network service cluster of the cloud platform through the public network access point indicated by the public network access point identifier and the public network service port number, and the private business data packet is transmitted through the secure connection.

6. The method according to claim 5, characterized in that, The method further includes: When the capability bit indication is not supported, receive the shutdown command sent by the cloud platform; In response to the shutdown command, the private service data packets are maintained to be transmitted through the private network access point.

7. The method according to claim 5, characterized in that, The login message also includes vehicle model information, which is used to instruct the cloud platform to determine the firmware version information corresponding to the vehicle. The method further includes: Receive firmware prompt information sent by the cloud platform based on the vehicle model information, wherein the firmware prompt information is determined based on the matching of the function configuration parameters indicated by the firmware version information with the capability bits; Based on the firmware prompt information, perform a firmware upgrade on the vehicle communication module.

8. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor is configured to call and run the executable program code from the memory, causing the vehicle to perform the vehicle network management method as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the network management method for the vehicle as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing a computer to perform the method according to any one of claims 1 to 7.

Images