Dynamic IP automatic adaptation method and device for 5G Internet of Vehicles, computer equipment and medium

Abstract

The embodiment of the invention provides a dynamic IP automatic adaptation method and device for the 5G Internet of Vehicles, computer equipment and a medium, and the method comprises the steps: carrying out the automatic detection of IP changes at a vehicle-mounted terminal, verifying the consistency of the detected IP changes in combination with multiple paths, and determining the IP changes as effective IP changes after the verification is passed; sending an IP change request to a server through a lightweight communication interface based on the effective IP change; and in the server, performing multi-level communication legality verification on the IP change request, and for the verified IP change request, controlling a plurality of service components to change the mapping relationship between the vehicle-mounted terminal and the IP in a security policy in a database based on a distributed consistency mode. According to the scheme, the IP change can be automatically detected, the mapping relation between the vehicle-mounted terminal and the IP is changed in the security policy in the database, and the problems of domain name resolution delay, security policy failure and the like are avoided.

Description

Technical Field

[0001] This invention relates to the fields of vehicle network communication and computer network management technology, and in particular to a dynamic IP automatic adaptation method, device, computer equipment and medium for 5G vehicle network. Background Technology

[0002] In a 5G private network environment, vehicle-to-everything (V2X) applications typically involve large-scale vehicle terminal access, frequent handovers in high-speed mobile environments, and dynamic addressing across base stations or network domains. Compared to traditional 4G networks, 5G private networks offer higher bandwidth, lower latency, and stronger slicing isolation capabilities, but they also bring the problem of dynamic allocation and frequent changes in terminal IP addresses. For vehicle terminals, the frequent switching of network nodes during vehicle operation causes their IP addresses to change frequently within a short period. If the new IP addresses cannot be identified and adapted in a timely and accurate manner, the following problems may occur: Domain name resolution delay: Because the terminal IP cannot be changed and synchronized to the resolution system in real time, the server may obtain an expired IP when resolving the domain name of the vehicle terminal, resulting in the inability to report location data or status information in real time; Security policy failure: If the security policy relies on a fixed IP or a static whitelist, and the policy configuration cannot be dynamically adjusted according to the terminal IP, access control anomalies or security risks will occur when the IP changes.

[0003] Currently, in 5G private network and vehicle-to-everything (V2X) scenarios, to address the issue of frequent IP address changes for vehicle terminals due to network switching or dynamic allocation within the private network, common technical solutions mainly fall into the following categories: (1) Static IP Management Scheme In this type of solution, vehicle-mounted terminals or dedicated network maintenance personnel ensure communication continuity by pre-assigning fixed IP addresses or maintaining static mapping relationships on the server side. The typical technical process includes: Fixed IP address: When the vehicle terminal accesses the 5G private network, a reserved fixed IP address is directly assigned by the core network gateway or DHCP server.

[0004] Static mapping: Manually configure the mapping relationship between terminal IPs and domain names or device identifiers in the hosts file or firewall policy on the server side.

[0005] Communication and interaction: The terminal establishes a communication connection with the server through a fixed IP address or a fixed domain name.

[0006] (2) Dynamic update scheme based on DNS resolution This type of solution utilizes a dedicated network's internal DNS server to maintain the mapping between domain names and terminal IP addresses, ensuring address updates through periodic refreshes or manual DNS resolution. Its typical technical process includes: Terminal registration: When the vehicle terminal starts up, it reports its IP address and domain name binding relationship to the private network DNS server.

[0007] DNS cache refresh: Clients or servers ensure timely DNS resolution results by setting a shorter TTL (Time To Live) period.

[0008] Domain name access: The server obtains the current IP address of the vehicle terminal through DNS resolution and initiates communication.

[0009] (3) Address preservation scheme based on mobile network protocol In some dedicated vehicle-to-everything (V2X) networks, mobility management protocols (such as MIPv6 and PMIPv6) or network slicing allocation strategies are used to maintain the relative stability of terminal logical addresses. The typical technical process includes: Anchor node binding: Assign a logical address (Home Address) to the vehicle terminal, and the anchor node is responsible for maintaining the mapping relationship between the address and the actual IP.

[0010] Tunnel forwarding: When a vehicle-mounted terminal undergoes a cross-base station handover or internal migration within a private network, data is forwarded to the terminal's latest actual IP address through a tunneling mechanism.

[0011] Transparent communication: Upper-layer applications always communicate through logical addresses without being aware of actual IP changes.

[0012] (4) Compensation scheme based on application layer heartbeat and reconnection mechanism Some connected vehicle applications do not specifically handle dynamic IPs, but instead rely on application-layer heartbeat detection and reconnection logic to ensure communication continuity. Their typical technical process includes: Heartbeat detection: The client periodically sends heartbeat packets, and the server determines whether the connection is interrupted by the heartbeat timeout.

[0013] Reconnection request: Once a connection loss due to an IP change is detected, the terminal establishes a new TCP / UDP connection by re-initiating a session.

[0014] Service recovery: The server resumes data interaction based on the new connection. However, all of the above technical solutions have drawbacks: (1) Static configuration lacks flexibility Existing solutions based on fixed IPs or static hosts configurations require pre-configuring the address mapping relationships of vehicle terminals on the server side or private network gateway. Once the IP of the vehicle terminal changes due to base station switching or address pool reallocation, the original mapping becomes invalid, requiring manual intervention to update. This cannot meet the high-frequency dynamic access requirements of a large number of terminals in the Internet of Vehicles, resulting in high maintenance costs and poor adaptability.

[0015] (2) DNS resolution updates are subject to delays and uncertainties. Solutions based on dedicated DNS servers typically rely on TTL values ​​to refresh records. If the TTL is too long, it can lead to delays in domain name resolution results; if the TTL is too short, it increases the load on the DNS server. Furthermore, the DNS cache refresh process can introduce delays of seconds or even minutes, which can cause data interruptions or false alarms in vehicle-to-everything (V2X) positioning and real-time data upload scenarios, thus failing to meet the low-latency requirements of vehicle-road cooperative systems.

[0016] (3) Mobility protocols introduce complexity and additional overhead While mobility management protocols such as MIPv6 and PMIPv6 can shield IP address changes, they require additional anchor nodes to maintain the mapping between logical and physical addresses, resulting in complex protocol stack implementations and high demands on dedicated network infrastructure. Furthermore, tunneling mechanisms introduce additional latency and bandwidth overhead, hindering the real-time reporting of massive amounts of data from vehicle sensors.

[0017] (4) Low efficiency of application layer heartbeat reconnection compensation Compensation mechanisms relying on heartbeats and reconnection are reactive, meaning connections can only be restored after a communication interruption, inevitably leading to data upload interruptions or loss. In high-frequency positioning and security monitoring scenarios within the Internet of Vehicles (IoV), this compensation method is insufficient to guarantee data continuity and integrity, and frequent reconnections also create additional network load.

[0018] (5) Insufficient security policy adaptation Most existing solutions focus on ensuring connection reachability and lack an automatic adaptation mechanism for security policies in the case of dynamic IPs. For example, access control based on static whitelists becomes invalid immediately after an IP change, which may lead to the terminal being denied access; while manual maintenance or periodic batch updates are not only lagging but also increase potential security risks.

[0019] Therefore, existing technologies cannot achieve a low-latency, secure IP adaptation solution. Summary of the Invention In view of this, embodiments of the present invention provide a dynamic IP automatic adaptation method for 5G vehicle-to-everything (V2X) networks to solve the technical problem that existing technologies cannot achieve low-latency and secure IP adaptation. The method includes: At the vehicle terminal, IP changes are automatically detected, and the consistency of the detected IP changes is verified by combining multiple paths. Once the verification is successful, the IP change is determined to be valid. Based on a valid IP change, an IP change request is sent to the server via a lightweight communication interface; On the server, in response to the IP change request, a multi-level communication validity verification is performed on the IP change request. For the verified IP change request, multiple service components are controlled to change the mapping relationship between the vehicle terminal and the IP in the security policy of the database in a distributed consistency manner.

[0020] This invention also provides a dynamic IP automatic adaptation device for 5G vehicle-to-everything (V2X) networks, to solve the technical problem that existing technologies cannot achieve low-latency and secure IP adaptation. The device includes: The IP change detection module is used to automatically detect IP changes in the vehicle terminal, and verify the consistency of the detected IP changes by combining multiple paths. If the verification is successful, it is determined to be a valid IP change. The IP change request sending module is used to send IP change requests to the server through a lightweight communication interface based on valid IP changes. The IP adaptation module, in response to the IP change request, performs multi-level communication legitimacy verification on the server. For the verified IP change request, it controls multiple service components to change the mapping relationship between the vehicle terminal and the IP address within the security policy of the database using a distributed consistency approach. This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned dynamic IP automatic adaptation methods for 5G vehicle-to-everything (V2X) networks, thereby solving the technical problem that existing technologies cannot achieve low-latency and secure IP adaptation.

[0021] This invention also provides a computer-readable storage medium storing a computer program that executes any of the above-described dynamic IP auto-adaptation methods for 5G vehicle-to-everything (V2X) networks, thereby solving the technical problem in the prior art that low-latency and secure IP adaptation cannot be achieved.

[0022] Compared with existing technologies, the beneficial effects achieved by at least one of the above-mentioned technical solutions adopted in the embodiments of this specification include at least the following: By establishing an IP change detection mechanism on the vehicle terminal side (e.g., detecting IP changes based on system event listening or periodic polling), and sending an IP change request to the server based on the latest valid IP address change via a lightweight interface protocol (RESTful API, CoAP, or MQTT), the latest IP changes are reported to the server in real time; the server temporarily stores IP information using an in-memory database (such as Redis) and automatically updates the mapping relationship between the vehicle terminal and the IP in the hosts file based on the IP change request. Simultaneously, combined with a distributed architecture and consistency control mechanism, multiple service components are controlled to change the mapping relationship between the vehicle terminal and the IP within the security policy of the database in a distributed consistency manner, ensuring that the correctness and consistency of the resolution results are maintained even in high-concurrency scenarios, thereby avoiding problems such as domain name resolution delay and security policy failure. Furthermore, an IP change confirmation mechanism can be introduced, combining multi-path verification of the detected IP changes to enhance the security, reliability, and stability of the data interaction process. The use of a lightweight communication interface helps reduce communication latency. Attached Figure Description

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

[0024] Figure 1 This is a flowchart of a dynamic IP automatic adaptation method for 5G vehicle-to-everything (V2X) provided in an embodiment of the present invention; Figure 2 This is a structural block diagram of a computer device provided in an embodiment of the present invention; Figure 3 This is a structural block diagram of a dynamic IP automatic adaptation device for 5G vehicle networking provided in an embodiment of the present invention. Detailed Implementation

[0025] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0026] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] In this embodiment of the invention, a dynamic IP automatic adaptation method for 5G vehicle-to-everything (V2X) is provided, such as... Figure 1 As shown, the method includes: Step S101: On the vehicle terminal, IP changes are automatically detected, and the consistency of the detected IP changes is verified by combining multiple paths. If the verification is successful, it is determined to be a valid IP change. Step S102: Based on the valid IP change, send an IP change request to the server through a lightweight communication interface; Step S103: On the server, in response to the IP change request, a multi-level communication legality verification is performed on the IP change request. For the verified IP change request, multiple service components are controlled to change the mapping relationship between the vehicle terminal and the IP in the security policy of the database based on a distributed consistency approach.

[0028] In practical implementation, to improve the accuracy and effectiveness of IP change detection by the vehicle terminal, an automatic IP change detection method is proposed. This method combines multi-path verification to confirm the consistency of detected IP changes. Once verification is successful, the IP changes identified as valid include: Automatically detects IP changes through multiple methods, and has detected new IPs; Send an echo request to the server to obtain the first source IP of the vehicle terminal; Echo requests are sent to multiple preset auxiliary detection nodes to obtain multiple second source IPs of the vehicle terminal; If the new IP, the first source IP, and the plurality of second source IPs are consistent, the new IP is determined to be a valid IP change; if the new IP, the first source IP, and the plurality of second source IPs are inconsistent, each inconsistent IP is taken as a candidate IP, the reliability of each candidate IP is evaluated, and the candidate IP with the highest reliability is determined to be a valid IP change.

[0029] In practice, IP changes can be automatically detected on the vehicle terminal side through various methods. The new IP obtained by the same detection method is identified as the detected new IP. For example, the detection method can be to use the netlink interface provided by the operating system to listen for address change events of the network interface in real time, and capture the new and old IP information and the time of change. Another detection method is to compare the current IP of the local network interface with the historical IP according to a preset period. If the comparison is inconsistent, an IP change occurs, so as to avoid incomplete detection due to missed system event detection.

[0030] In practice, the vehicle terminal can call the https: / / ifconfigserver / ip class interface to send an echo request to the server, which will return the source IP of the vehicle terminal it observes. This is used to confirm the accuracy of the new IP detected by the vehicle terminal, so as to further ensure the accuracy of IP change detection.

[0031] In practical implementation, to further ensure the accuracy of IP change detection, a method is proposed to send echo requests to multiple preset auxiliary detection nodes to obtain multiple second source IPs of the vehicle terminal, which are used to confirm the accuracy of the new IP detected by the vehicle terminal. For example, after detecting an IP change, the vehicle terminal not only sends an echo confirmation to the main server, but also sends echo requests in parallel to multiple preset auxiliary detection nodes (such as edge nodes or CDN probes in different regions). The consistency of the multiple second source IP results of the vehicle terminal returned by the multiple preset auxiliary detection nodes is compared with the new IP of the vehicle terminal's local detection result.

[0032] In practice, there may be differences between the second source IP results returned by different preset auxiliary detection nodes, and there may also be inconsistencies between the new IP, the first source IP, and the second source IP. To determine reliable and valid changed IPs, an evaluation of the reliability of each candidate IP is proposed, including: The reliability value for each candidate IP is calculated using the following formula:

[0033] in, This is a reliability value. This indicates the average latency of the candidate IP; lower latency is better. This indicates the packet loss rate of the candidate IP. This indicates the historical stability of the candidate IP, which is the proportion of the candidate IP that is confirmed as valid within the pre-examination period, and the value ranges from 0 to 1. , , These are all weighting coefficients, which can be dynamically adjusted according to the environment. For example, the default values ​​are 0.5, 0.3, and 0.2.

[0034] Specifically, in evaluating the reliability of candidate IPs, three dimensions—latency, availability, and historical stability—are introduced for comprehensive calculation. The use of historical stability can effectively suppress the interference of short-term network fluctuations or anomaly detection results on decision-making, improving the accuracy and robustness of dynamic IP determination. This method is simple to implement, has low computational overhead, and is both innovative and practical.

[0035] In practice, after a valid IP change is determined on the vehicle terminal side, the vehicle terminal generates change reporting data. The change reporting data includes key location information of the current network status, such as the change data of fields like terminal identifier, old IP, new IP, timestamp, and slice identifier. A unique idempotent identifier is generated for this reporting data to prevent duplicate processing. The change reporting data is sent to the server in the form of an IP change request.

[0036] In practical implementation, to reduce latency during the process of sending IP change requests to the server, a lightweight communication interface is proposed for sending IP change requests to the server, including: In the REST interface scenario, the vehicle terminal sends an IP change request to the server via the POST / api / v1 / ip / changed interface; HTTP / 2 is used for transmission, the message body is encapsulated in JSON format, and the transmission process carries an OAuth token and a two-way TLS certificate to complete identity authentication. In the CoAP interface scenario, the vehicle terminal sends an IP change request to the server through the POSTcoap: / / server:5683 / ip-change interface, uses DTLS and X.509 certificates or pre-shared keys for encryption and authentication, and the reported data can be in JSON encoding, which is suitable for low power consumption and weak network environments.

[0037] In practice, if the process of sending an IP change request fails due to network interruption, the vehicle terminal will request to hold the request temporarily and automatically retry according to the exponential backoff strategy until the report is successfully submitted.

[0038] In practice, after receiving an IP change request from the vehicle terminal, the server performs multi-level communication legitimacy verification on the IP change request, for example, First, the security credentials are verified, including OAuth token verification, certificate fingerprint verification, and whitelist matching.

[0039] Secondly, for requests that have passed security credential authentication, the server performs further semantic validity checks, such as IP address format, terminal identifier validity, and timestamp validity.

[0040] Finally, the server checks whether the idempotency flag has been processed. If so, it's a duplicate request, and a completed status is returned directly to avoid duplicate writing. If not, it's a new request. A request that passes all the above multi-level communication validity checks is a verified IP change request.

[0041] In practice, for verified IP change requests, the server establishes or updates the mapping relationship between the vehicle terminal and the IP within the security policy in the Redis database, while maintaining the IP version number information so that the vehicle terminal can obtain the security policy based on the real-time updated IP, thereby avoiding abnormal access.

[0042] In practical implementation, to ensure the consistency and correctness of mapping relationship changes under high-concurrency scenarios, a method is proposed to control multiple service components to change the mapping relationship between the vehicle terminal and the IP within the security policy of the database based on distributed consistency. This includes: The verified IP change request is placed in a message queue. For multiple service components consuming the message queue, only one service component is allowed to acquire the distributed lock at the same time, and other service components that fail to acquire the distributed lock will be blocked. For multiple processes or threads in the service component that have acquired the distributed lock, only one process or thread is allowed to acquire the file lock at any given time. The process or thread that has acquired the file lock is allowed to change the mapping relationship between the vehicle terminal and the IP address within the security policy in the database based on the verified IP change request and after verification of the IP version number.

[0043] Specifically, this process of changing mapping relationships based on distributed locks and file locks proposes a layered control process to address the issue of data conflicts and overwriting that may occur when multiple nodes and processes concurrently write to the same hosts file. This process includes cluster-level control, node-level control, and data-level control, as detailed below: First, in a clustered environment, the system uses etcd distributed locks to ensure global uniqueness. When multiple nodes (i.e., multiple service components consuming the message queue) attempt to write simultaneously, only one node can successfully acquire the distributed lock, while other nodes will be blocked, thus ensuring that only one node enters the write process in a cross-node environment.

[0044] Secondly, within the node that successfully acquires the distributed lock (i.e., the service component that acquires the distributed lock), a file lock (flock) is used to further control the local write process or thread for mutual exclusion. This ensures that even if multiple concurrent write requests exist on the same node, only one process or thread can enter the file write phase at a time, avoiding conflicts caused by local contention.

[0045] Finally, before writing to the file, an IP version number comparison can be performed using Redis transactions or Lua scripts to confirm that the data being written is up-to-date. Specifically, if the comparison result shows that the current version number is higher than or equal to the latest version number recorded in Redis (i.e., verified by IP version number), the write operation is allowed, and the IP version number is updated simultaneously; if the comparison result shows an outdated version, the write operation is rejected, thus preventing old data from overwriting new data.

[0046] Through the above layered control mechanism, uniqueness, mutual exclusion, and correctness can be guaranteed at the cluster level, node level, and data level, respectively, realizing a safe and reliable file update process. Compared with existing solutions that rely solely on a single lock mechanism, this method effectively solves the data consistency problem in cross-node and multi-process scenarios by introducing a combined strategy of distributed locks, local file locks, and version number comparison. It has strong innovation and practicality, ensuring both mutual exclusion in multi-node environments and consistency and correctness of data writes, thereby achieving atomic updates and highly reliable maintenance of the hosts file.

[0047] In practical implementation, to reduce the risks and overhead of writing the entire file, a progressive hot update mechanism is proposed to change the mapping relationship between the vehicle terminal and the IP address. For example, the mapping relationship between the vehicle terminal and the IP address is changed within the security policy of the database, including: The original hosts file containing the mapping relationship is split into multiple independent fragment files. Based on the new IP and its version number in the verified IP change request, the mapping relationship between the vehicle terminal and the IP is changed in the corresponding fragment file. After the IP change, the fragment files are concatenated into a temporary hosts file. The original hosts file is backed up, and then the temporary hosts file is replaced with the official hosts file through an atomic replacement operation. This achieves the goal of not replacing the entire file every time a new hosts file is generated. Instead, the mapping between the vehicle terminal and the IP is split into multiple independent fragment files and stored in the / etc / hosts.d / directory. During the update, only the fragment files that have changed (i.e., the fragment files corresponding to the new IP) are replaced. Then, the fragment files are dynamically concatenated through symbolic links or aggregation scripts to generate the final / etc / hosts file (i.e., the official hosts file).

[0048] Specifically, once the new file (i.e. the official hosts file) is ready, a lightweight reload signal is sent to critical processes (such as DNS caching service and proxy service) to avoid DNS resolution interruption or service jitter caused by forced restart.

[0049] Specifically, the new IP address is first written to a temporary file (i.e., a temporary hosts file). After the writing is complete, the temporary file is replaced with the official / etc / hosts file using an atomic substitution operation (such as the mv command). This atomic substitution operation ensures the consistency and integrity of the file update.

[0050] Before the replacement operation, the original hosts file is backed up to a specified path (such as / etc / hosts.bak), recording the timestamp and version number, so that a quick rollback can be performed in case of an anomaly. If the new file (i.e., the temporary file) fails to load or the service malfunctions, the system can quickly roll back based on the backup file, ensuring the high availability of critical configurations.

[0051] This "fragmentation + hot update" approach significantly reduces the risks and overhead of writing the entire file while ensuring atomicity and rollback capabilities, making it particularly suitable for high-frequency IP changes in large-scale concurrent scenarios.

[0052] In practice, a security and conflict control mechanism is provided, using a multi-factor authentication mechanism (terminal certificate + OAuth token + device fingerprint) to authenticate the vehicle terminal. For concurrent update scenarios, a combination of IP version number comparison and distributed locking is used for conflict detection and control. If a conflict is detected, the update is rejected and the vehicle terminal is prompted to obtain the latest IP status. The vehicle terminal whitelist is updated and maintained regularly, and any IP change requests from vehicle terminals not on the whitelist are rejected.

[0053] In practical implementation, to maintain stable processing capabilities under large-scale concurrency, the above methods also include: Monitor the message queue's backlog depth, consumption latency, and peak rate of IP change events. When any one of these factors reaches a preset threshold, trigger Kubernetes dynamic scaling to add container replicas that handle the mapping change events.

[0054] Specifically, unlike conventional CPU / memory-based automatic scaling, this application proposes an adaptive scaling mechanism based on business queue pressure: real-time monitoring of metrics such as the backlog depth of the Kafka message queue, consumption latency, and peak rate of IP change events; when the metrics exceed preset thresholds, Kubernetes dynamic scaling is automatically triggered to increase the number of container replicas that handle host file update events, thereby improving the ability to handle atomic updates and conflict control of the host file; when the message queue metrics return to a low level, scaling is gradually reduced to save resources.

[0055] Specifically, during the scaling up and down process, a health probe detection and failure rollback mechanism are introduced to ensure the availability of new container replicas and avoid service instability caused by scaling failures. Specifically, the health probe in this application not only detects the liveness status of container replicas but also performs a "business-level verification" immediately after the container replica starts. For example, it attempts to consume a test message from Kafka and simulate writing to the hosts file. If consumption or writing fails within a preset time, the verification fails, and the container replica is deemed unavailable. Once an unavailable container replica is detected, a rollback mechanism is automatically triggered: the scaling operation is revoked, the number of container replicas is restored to the stable value before scaling, and the reason for the failure is recorded in the monitoring log. In this way, lock contention, write conflicts, or consumption delays caused by abnormal container replicas being added to the cluster can be avoided, thereby ensuring the stability of the overall system. The use of health probe detection and failure rollback mechanisms achieves closed-loop control of "resource scaling → business verification → only effective upon success," demonstrating stronger practicality and innovation.

[0056] Specifically, message queues are used to achieve asynchronous decoupling between various processing steps: IP change events are reported from the vehicle terminal to the server's message queue, and the service component consuming the message queue asynchronously processes the hosts file update. In high-concurrency scenarios, the message queue queues events, and in conjunction with the multi-layered coordination mechanism of etct distributed locks, fill file locks, and Redis transactions, it ensures that the writes to the hosts file for each event are both mutually exclusive and consistent, thus maintaining stable processing capabilities even under large-scale concurrency.

[0057] In practice, as shown in Table 1 below, the above-mentioned dynamic IP automatic adaptation method for 5G vehicle networking has many advantages over existing technologies.

[0058] Table 1

[0059] In this embodiment, a computer device is provided, such as... Figure 2As shown, it includes a memory 201, a processor 202, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned dynamic IP automatic adaptation methods for 5G vehicle networking.

[0060] Specifically, the computer device can be a computer terminal, a server, or a similar computing device.

[0061] In this embodiment, a computer-readable storage medium is provided, which stores a computer program that executes any of the above-described dynamic IP auto-adaptation methods for 5G vehicle-to-everything (V2X) networks.

[0062] Specifically, computer-readable storage media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable storage media does not include transient media, such as modulated data signals and carrier waves.

[0063] Based on the same inventive concept, this invention also provides a dynamic IP automatic adaptation device for 5G vehicle-to-everything (V2X) networks, as described in the following embodiments. Since the principle of the dynamic IP automatic adaptation device for 5G V2X networks is similar to that of the dynamic IP automatic adaptation method for 5G V2X networks, the implementation of the dynamic IP automatic adaptation device for 5G V2X networks can refer to the implementation of the dynamic IP automatic adaptation method for 5G V2X networks, and repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0064] Figure 3 This is a structural block diagram of a dynamic IP automatic adaptation device for 5G vehicle-to-everything (V2X) according to an embodiment of the present invention, such as... Figure 3 As shown, it includes: The IP change detection module 301 is used to automatically detect IP changes in the vehicle terminal, verify the consistency of the detected IP changes by combining multiple paths, and determine the IP change as valid after the verification is passed. IP change request sending module 302 is used to send an IP change request to the server through a lightweight communication interface based on a valid IP change; The IP adaptation module 303 is used on the server to perform multi-level communication legality verification on the IP change request in response to the IP change request, and to control multiple service components to change the mapping relationship between the vehicle terminal and the IP in the security policy of the database based on a distributed consistency approach for the verified IP change request.

[0065] In one embodiment, the IP change detection module is used to automatically detect IP changes through multiple methods, detect new IPs, send an echo request to the server to obtain the first source IP of the vehicle terminal, send echo requests to multiple preset auxiliary detection nodes to obtain multiple second source IPs of the vehicle terminal, determine that the new IP is a valid IP change if the new IP, the first source IP, and the multiple second source IPs are consistent, and if the new IP, the first source IP, and the multiple second source IPs are inconsistent, each inconsistent IP is used as a candidate IP, the reliability of each candidate IP is evaluated, and the candidate IP with the highest reliability is determined as a valid IP change.

[0066] In one embodiment, the IP change detection module is used to calculate the reliability value of each candidate IP using the following formula:

[0067] in, This is a reliability value. This indicates the average latency of the candidate IP. This indicates the packet loss rate of the candidate IP. This indicates the historical stability of the candidate IP, which is the percentage of times the candidate IP has been confirmed as valid within the pre-screening period. , , All are weighting coefficients.

[0068] In one embodiment, the IP change request sending module is used to send an IP change request to the server via the POST / api / v1 / ip / changed interface in a REST interface scenario; and to send an IP change request to the server via the POSTcoap: / / server:5683 / ip-change interface in a CoAP interface scenario.

[0069] In one embodiment, the IP adaptation module is used to place the verified IP change request into a message queue. For multiple service components consuming the message queue, only one service component is allowed to acquire the distributed lock at any given time, and other service components that fail to acquire the distributed lock will be blocked. For multiple processes or threads in the service component that has acquired the distributed lock, only one process or thread is allowed to acquire the file lock at any given time. The process or thread that acquires the file lock is allowed to change the mapping relationship between the vehicle terminal and the IP address within the security policy in the database based on the verified IP change request and after verification by the IP version number.

[0070] In one embodiment, the IP adaptation module is used to split the original hosts file containing the mapping relationship into multiple independent fragment files, change the mapping relationship between the vehicle terminal and the IP in the corresponding fragment files based on the new IP and its version number in the verified IP change request, and after the IP change, concatenate the fragment files into a temporary hosts file, back up the original hosts file, and replace the temporary hosts file with the official hosts file through an atomic replacement operation.

[0071] In one embodiment, the IP adaptation module is further configured to monitor the backlog depth, consumption latency, and peak rate of IP change events in the message queue. When any one of the backlog depth, consumption latency, and peak rate of IP change events reaches the corresponding preset threshold, Kubernetes dynamic scaling is triggered to add container replicas to handle the mapping relationship change events.

[0072] This invention achieves the following technical effects: By establishing an IP change detection mechanism on the vehicle terminal side (e.g., detecting IP changes based on system event listening or periodic polling), and sending IP change requests to the server based on the latest valid IP address changes via a lightweight interface protocol (RESTful API, CoAP, or MQTT), the latest IP changes are reported to the server in real time. The server temporarily stores IP information using an in-memory database (such as Redis) and automatically updates the mapping relationship between vehicle terminals and IPs in the hosts file based on IP change requests. Simultaneously, combined with a distributed architecture and consistency control mechanism, multiple service components are controlled to change the mapping relationship between vehicle terminals and IPs within the security policy of the database in a distributed consistency manner, ensuring the correctness and consistency of the parsing results even in high-concurrency scenarios. Furthermore, an IP change confirmation mechanism can be introduced, combining multi-path verification to check the consistency of detected IP changes, thereby enhancing the security, reliability, and stability of the data interaction process. The use of a lightweight communication interface helps reduce latency.

[0073] Obviously, those skilled in the art should understand that the modules or steps of the above-described embodiments of the present invention can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of the present invention are not limited to any particular hardware and software combination.

[0074] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations can be made to the embodiments of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A dynamic IP automatic adaptation method for 5G vehicle-to-everything (V2X) networks, characterized in that, include: At the vehicle terminal, IP changes are automatically detected, and the consistency of the detected IP changes is verified by combining multiple paths. Once the verification is successful, the IP change is determined to be valid. Based on a valid IP change, an IP change request is sent to the server via a lightweight communication interface; On the server, in response to the IP change request, a multi-level communication validity verification is performed on the IP change request. For the verified IP change request, multiple service components are controlled to change the mapping relationship between the vehicle terminal and the IP in the security policy of the database in a distributed consistency manner.

2. The method as described in claim 1, characterized in that, Automatically detect IP changes, and verify the consistency of detected IP changes using multi-path analysis. Once verification is successful, the IP changes deemed valid include: Automatically detects IP changes through multiple methods, and has detected new IPs; Send an echo request to the server to obtain the first source IP of the vehicle terminal; Echo requests are sent to multiple preset auxiliary detection nodes to obtain multiple second source IPs of the vehicle terminal; If the new IP, the first source IP, and the plurality of second source IPs are consistent, the new IP is determined to be a valid IP change; if the new IP, the first source IP, and the plurality of second source IPs are inconsistent, each inconsistent IP is taken as a candidate IP, the reliability of each candidate IP is evaluated, and the candidate IP with the highest reliability is determined to be a valid IP change.

3. The method as described in claim 2, characterized in that, Evaluate the reliability of each candidate IP, including: The reliability value for each candidate IP is calculated using the following formula: in, This is a reliability value. This indicates the average latency of the candidate IP. This indicates the packet loss rate of the candidate IP. This indicates the historical stability of the candidate IP, which is the percentage of times the candidate IP has been confirmed as valid within the pre-screening period. , , All are weighting coefficients.

4. The method as described in claim 1, characterized in that, Sending an IP change request to the server via a lightweight communication interface includes: In a REST interface scenario, the vehicle terminal sends an IP change request to the server via the POST / api / v1 / ip / changed interface; In the CoAP interface scenario, the vehicle terminal sends an IP change request to the server through the POSTcoap: / / server:5683 / ip-change interface.

5. The method according to any one of claims 1 to 4, characterized in that, Controlling multiple service components to change the mapping relationship between the vehicle terminal and IP address within the security policy of the database in a distributed consistency manner includes: The verified IP change request is placed in a message queue. For multiple service components consuming the message queue, only one service component is allowed to acquire the distributed lock at the same time, and other service components that fail to acquire the distributed lock will be blocked. For multiple processes or threads in the service component that have acquired the distributed lock, only one process or thread is allowed to acquire the file lock at any given time. The process or thread that has acquired the file lock is allowed to change the mapping relationship between the vehicle terminal and the IP address within the security policy in the database based on the verified IP change request and after verification of the IP version number.

6. The method as described in claim 5, characterized in that, Modifying the mapping relationship between the vehicle terminal and IP within the security policy of the database includes: The original hosts file containing the mapping relationship is split into multiple independent fragment files. Based on the new IP and its version number in the verified IP change request, the mapping relationship between the vehicle terminal and the IP is changed in the corresponding fragment file. After the IP change, the fragment files are concatenated into a temporary hosts file. After backing up the original hosts file, the temporary hosts file is replaced with the official hosts file through an atomic replacement operation.

7. The method as described in claim 5, characterized in that, Also includes: Monitor the message queue's backlog depth, consumption latency, and peak rate of IP change events. When any one of these factors reaches a preset threshold, trigger Kubernetes dynamic scaling to add container replicas that handle the mapping change events.

8. A dynamic IP automatic adaptation device for 5G vehicle-to-everything (V2X) networks, characterized in that, include: The IP change detection module is used to automatically detect IP changes in the vehicle terminal, and verify the consistency of the detected IP changes by combining multiple paths. If the verification is successful, it is determined to be a valid IP change. The IP change request sending module is used to send IP change requests to the server through a lightweight communication interface based on valid IP changes. The IP adaptation module is used on the server to perform multi-level communication legality verification on the IP change request in response to the IP change request, and to control multiple service components to change the mapping relationship between the vehicle terminal and the IP in the security policy of the database based on distributed consistency for the verified IP change request.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the dynamic IP automatic adaptation method for 5G vehicle networking as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that performs the dynamic IP auto-adaptation method for 5G vehicle-to-everything (V2X) as described in any one of claims 1 to 7.

Images