Edge server switching method, electronic device, storage medium, and program product

Abstract

The application provides an edge server switching method, an electronic device, a storage medium and a program product, relates to the technical field of Internet of Things, and is used in the scene of edge server control of a vehicle. Seamless switching of multiple edge servers is realized through a pre-connection mode. The method comprises the following steps: acquiring driving data of the vehicle and server information of multiple edge servers; the driving data comprises the position, speed and heading angle of the vehicle, and the server information comprises the space-time correlation characteristics and load state of the edge servers; the driving trajectory of the vehicle is predicted based on the driving data, and a predicted trajectory is obtained; based on the server information and the driving data, a target edge server that meets a preset condition is determined from the multiple edge servers; the vehicle is instructed to establish a communication connection with the target edge server, and when the driving data and / or the server information of the current edge server meets a switching condition, the vehicle is switched to the target edge server for service provision.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to an edge server switching method, electronic device, storage medium, and program product. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology, remote vehicle control has become one of the core functions of intelligent vehicles, widely used in scenarios such as remote parking, emergency braking, and vehicle status monitoring. To achieve efficient and safe remote control, building a low-latency, high-reliability communication architecture is crucial.

[0003] Currently, mainstream vehicle remote control technologies primarily rely on a centralized cloud architecture. In this model, remote control commands are transmitted via mobile communication networks to a central cloud server, which then processes and forwards them before finally reaching the target vehicle. While this architecture can achieve basic remote control functions, the long data transmission path typically results in high end-to-end latency, and latency fluctuates dramatically during network congestion, making it difficult to meet the demands of control scenarios with extremely high real-time requirements.

[0004] To address these issues, the industry has begun to introduce edge computing technology. By deploying computing nodes closer to the network edge of vehicles, the physical distance for command transmission is shortened, thereby reducing network latency to some extent. However, existing edge server management often employs a passive mechanism, which frequently leads to delayed switchover and the risk of service interruption. Summary of the Invention

[0005] This application provides an edge server switching method, electronic device, storage medium, and program product. By acquiring vehicle driving data and surrounding edge server status information in real time, the future driving trajectory of the vehicle is predicted. Then, based on the trajectory and server status, a target edge server that can cover the trajectory is pre-selected and a connection is established. Finally, when specific switching conditions are met, the service is seamlessly migrated from the current server to the target server. This solves the technical problems in current vehicle remote control solutions, which use passive switching mechanisms and a single evaluation dimension, resulting in delayed edge server switching, high risk of service interruption, and difficulty in adapting to high-speed vehicle movement trajectories, thus failing to balance control real-time performance, continuity, and reliability.

[0006] In a first aspect, this application provides an edge server switching method, comprising: acquiring vehicle driving data and server information of multiple edge servers; the driving data includes the vehicle's position, speed, and heading angle, and the server information includes the spatiotemporal correlation characteristics and load status of the edge servers, the multiple edge servers including the current edge server currently providing services to the vehicle; predicting the vehicle's driving trajectory based on the driving data to obtain a predicted trajectory; determining a target edge server that meets preset conditions from the multiple edge servers based on the server information and driving data; the service range of the target edge server covering the predicted trajectory; instructing the vehicle to establish a communication connection with the target edge server, and switching to the target edge server to provide services to the vehicle when the driving data and / or the server information of the current edge server meet the switching conditions.

[0007] The technical solution provided in this application offers at least the following benefits: First, by acquiring vehicle position, speed, heading angle, and other driving data, as well as the spatiotemporal correlation characteristics and load status of edge servers, the solution clarifies the vehicle's current motion state and the real-time resource distribution of the edge network, providing data support for subsequent decision-making. Based on this, the solution predicts the vehicle's trajectory using driving data, enabling advance knowledge of the vehicle's future spatial location and effectively overcoming the handover lag caused by the lack of mobility prediction in traditional solutions. Subsequently, by combining the predicted trajectory with server information, a target edge server whose service range can cover the predicted trajectory is selected from multiple edge servers, ensuring the service continuity and adaptability of candidate nodes along the vehicle's future driving path. Finally, the solution instructs the vehicle to establish a communication connection with the target edge server in advance and completes the service handover when the handover conditions are met. This pre-connection mechanism effectively avoids communication interruptions and service delays that may occur during traditional passive handover, significantly improving the smoothness and reliability of edge server handover and ensuring the real-time and continuous remote control of the vehicle during movement.

[0008] In one possible implementation, a target edge server that meets preset conditions is determined from multiple edge servers based on server information, including: mapping server information and driving data into multiple evaluation dimensions; each evaluation dimension having a corresponding evaluation weight; for each edge server, determining the evaluation score of the edge server based on the multiple evaluation dimensions and the corresponding evaluation weights; determining the target edge server based on the evaluation score of each edge server; the evaluation score of the target edge server being greater than or equal to a first preset score.

[0009] Based on the above implementation method, by mapping server information and driving data to multiple evaluation dimensions and assigning corresponding weights, a quantitative evaluation of the comprehensive performance of edge servers is achieved, effectively overcoming the limitations of traditional solutions that rely on only a single indicator for decision-making. Furthermore, for each candidate edge server, a comprehensive evaluation score is calculated by combining multi-dimensional indicators and their weights, enabling a comprehensive and accurate measurement of the overall service capabilities of each node in terms of spatiotemporal correlation, network quality, and resource status. Finally, by setting a first preset score as a screening threshold, only edge servers that meet the evaluation score are selected as target nodes, ensuring that the finally selected servers can meet the current and future service needs of the vehicle in all key indicators. This significantly improves the rationality of edge server selection and further guarantees low latency and high reliability during vehicle remote control.

[0010] In one implementation, the method further includes: adjusting the evaluation weights corresponding to multiple evaluation dimensions when the driving data and / or server information meet the weight adjustment conditions.

[0011] Based on the above implementation, by dynamically adjusting the weights of evaluation dimensions when driving data or server information meets specific conditions, the edge server selection strategy can adaptively optimize according to changes in vehicle driving status and network environment. This dynamic weight adjustment mechanism effectively overcomes the poor adaptability of fixed weight strategies in complex and ever-changing scenarios, making the determination of target edge servers more aligned with actual operational needs, further improving the flexibility and rationality of switching decisions, and ensuring high-quality service continuity under different operating conditions.

[0012] In one implementation, the spatiotemporal correlation features include the network latency, packet loss rate, and server location of the edge server; the load status includes the communication cost and load occupancy rate of the edge server; and the weight adjustment conditions include: network latency greater than a preset latency; and / or, packet loss rate greater than a preset packet loss rate; and / or, distance between the edge server and the vehicle greater than a preset distance; and / or, vehicle speed greater than a preset speed; and / or, communication cost greater than a preset cost; and / or, load occupancy rate greater than a preset occupancy rate.

[0013] Based on the above implementation, the specific triggering conditions for weight adjustment are further refined. Key indicators such as network latency, packet loss rate, server location, vehicle speed, communication cost, and load occupancy are set as thresholds, enabling the implementation entity to accurately perceive abnormal fluctuations in vehicle driving status and the edge network environment. When any of the above indicators exceeds the preset range, the weight adjustment mechanism is triggered. This dynamic response mechanism based on multi-source data thresholds not only enhances the adaptability of the edge server switching strategy but also ensures that, under complex and ever-changing actual operating conditions, the implementation entity can flexibly balance multiple requirements such as real-time performance, reliability, and economy, thereby effectively improving the rationality of target edge server selection and the stability of the overall service.

[0014] In one implementation, the sum of the weights of multiple evaluation dimensions is 1. The evaluation weights corresponding to these dimensions are adjusted, including: increasing the evaluation weight of network latency and decreasing the evaluation weights of distance and communication cost when network latency is greater than a preset latency; and / or increasing the evaluation weight of packet loss rate and decreasing the evaluation weights of distance and communication cost when packet loss rate is greater than a preset packet loss rate; and / or increasing the evaluation weight of distance and decreasing the evaluation weight of communication cost when the distance between the edge server and the vehicle is greater than a preset distance; and / or increasing the evaluation weight of speed and decreasing the evaluation weight of communication cost when the vehicle speed is greater than a preset speed; and / or increasing the evaluation weight of communication cost and decreasing the evaluation weights of network latency, packet loss rate, and distance when communication cost is greater than a preset cost; and / or increasing the evaluation weight of load occupancy and decreasing the evaluation weight of communication cost when load occupancy is greater than a preset load occupancy.

[0015] Based on the above implementation, and under the constraint that the sum of weights is always 1, specific and differentiated weight adjustment directions are defined for different abnormal scenarios such as network latency, packet loss rate, distance, speed, communication cost, and load occupancy. This allows the evaluation process to adaptively reconstruct based on actual operating conditions. This weight redistribution mechanism not only ensures the normalization of weights for each evaluation dimension but also achieves precise tilting of evaluation strategies under different abnormal scenarios. This ensures that the selection of target edge servers always aligns with the most urgent service needs, further improving the intelligence level of switching decisions and the robustness of the overall system.

[0016] In one implementation, the switching conditions include: the vehicle leaving the coverage area of ​​the current edge server within a preset time; and / or, the evaluation score of the current edge server being less than or equal to a second preset score.

[0017] Based on the above implementation, by setting specific switching trigger conditions, a clear and quantifiable decision-making basis is provided for edge server switching, effectively avoiding the problems of ambiguous switching timing or reliance on manual intervention in traditional solutions. Specifically, using whether the vehicle leaves the current edge server's coverage area within a preset time as a switching condition allows the executing entity to predict service boundaries in advance based on the vehicle's location and movement trends, proactively triggering a switch before the vehicle leaves the coverage area, thus preventing service interruptions due to signal attenuation or disconnection. Using whether the current edge server's evaluation score falls below a second preset score as another switching condition allows the executing entity to monitor the overall performance status of the current service node in real time. Once key indicators such as network quality and load level deteriorate to an unacceptable level, the switching process can be initiated promptly, preventing vehicles from continuing to rely on degraded servers. These two conditions complement each other, covering both spatial coverage issues caused by vehicle mobility and scenarios of server performance degradation, jointly ensuring the accuracy and timeliness of switching timing, further improving the continuity and reliability of vehicle remote control services.

[0018] In one implementation, switching to a target edge server to provide services for the vehicle includes: synchronizing the vehicle's current session state to the target edge server; routing the vehicle's communication traffic with the current edge server to the target edge server; and instructing the vehicle to release its communication connection with the current edge server.

[0019] Based on the above implementation, a smooth and seamless edge server handover process is achieved through orderly steps of session state synchronization, traffic routing switching, and releasing old connections. First, before the handover, the vehicle's current session state is synchronized to the target edge server, allowing the target server to fully inherit the vehicle's control context information and preventing the loss or duplicate execution of control commands caused by session reconstruction during the handover. Then, communication traffic is routed from the current edge server to the target edge server, ensuring that control data flow is directed to the new node before the handover is completed on the vehicle side, thus achieving data path continuity. Finally, after traffic routing is completed, the vehicle is instructed to release its connection with the current edge server. This "connect first, then disconnect" mechanism effectively eliminates the communication gap caused by disconnecting the old connection and establishing a new one during traditional handover processes. This ensures uninterrupted transmission of vehicle remote control commands during the handover process, significantly reducing handover latency and packet loss risk, and further improving the continuity and reliability of vehicle remote control services.

[0020] Secondly, this application provides an edge server switching device, comprising: The acquisition module is used to acquire vehicle driving data and server information of multiple edge servers. The driving data includes the vehicle's position, speed and heading angle, and the server information includes the spatiotemporal correlation characteristics and load status of the edge servers. Among the multiple edge servers, there is the current edge server that is currently providing services to the vehicle. The processing module is used to predict the vehicle's trajectory based on driving data to obtain the predicted trajectory; The processing module is also used to determine the target edge server that meets the preset conditions from multiple edge servers based on server information and driving data; the service range of the target edge server covers the predicted trajectory. The control module is used to instruct the vehicle to establish a communication connection with the target edge server, and to switch to the target edge server to provide services to the vehicle when the driving data and / or the server information of the current edge server meet the switching conditions.

[0021] In one implementation, the processing module is further configured to map server information and driving data into multiple evaluation dimensions; each evaluation dimension has a corresponding evaluation weight; for each edge server, an evaluation score of the edge server is determined based on the multiple evaluation dimensions and the corresponding evaluation weights; a target edge server is determined based on the evaluation score of each edge server; the evaluation score of the target edge server is greater than or equal to a first preset score.

[0022] In one implementation, the processing module is further configured to adjust the evaluation weights corresponding to multiple evaluation dimensions when the driving data and / or server information meet the weight adjustment conditions.

[0023] In one implementation, the spatiotemporal correlation features include the network latency, packet loss rate, and server location of the edge server; the load status includes the communication cost and load occupancy rate of the edge server; and the weight adjustment conditions include: network latency greater than a preset latency; and / or, packet loss rate greater than a preset packet loss rate; and / or, distance between the edge server and the vehicle greater than a preset distance; and / or, vehicle speed greater than a preset speed; and / or, communication cost greater than a preset cost; and / or, load occupancy rate greater than a preset occupancy rate.

[0024] In one implementation, the sum of the weights of multiple evaluation dimensions is 1. The processing module is further configured to: increase the evaluation weight of network latency and decrease the evaluation weight of distance and communication cost when network latency is greater than a preset latency; and / or, increase the evaluation weight of packet loss rate and decrease the evaluation weight of distance and communication cost when packet loss rate is greater than a preset packet loss rate; and / or, increase the evaluation weight of distance and decrease the evaluation weight of communication cost when the distance between the edge server and the vehicle is greater than a preset distance; and / or, increase the evaluation weight of speed and decrease the evaluation weight of communication cost when the vehicle speed is greater than a preset speed; and / or, increase the evaluation weight of communication cost and decrease the evaluation weight of network latency, packet loss rate, and distance when communication cost is greater than a preset cost; and / or, increase the evaluation weight of load occupancy and decrease the evaluation weight of communication cost when load occupancy is greater than a preset load occupancy.

[0025] In one implementation, the switching conditions include: the vehicle leaving the coverage area of ​​the current edge server within a preset time; and / or, the evaluation score of the current edge server being less than or equal to a second preset score.

[0026] In one implementation, the control module is further configured to: synchronize the vehicle's current session state to the target edge server; route the communication traffic between the vehicle and the current edge server to the target edge server; and instruct the vehicle to release the communication connection with the current edge server.

[0027] Thirdly, this application provides an electronic device, including: a processor and a memory, the processor being coupled to the memory; the memory being used to store computer instructions, which are loaded and executed by the processor to enable the computer device to implement the method described in the first aspect.

[0028] Fourthly, this application provides a computer-readable storage medium comprising: computer software instructions; which, when executed in an electronic device, cause the electronic device to implement the method described in the first aspect.

[0029] Fifthly, this application provides a computer program product comprising a computer program; when the computer program is run in an electronic device, it causes the electronic device to implement the method described in the first aspect.

[0030] The beneficial effects of the second to fifth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description

[0031] Figure 1 An architecture diagram of the remote control system provided in the embodiments of this application; Figure 2A flowchart illustrating an edge server switching method provided in an embodiment of this application; Figure 3 A comparative diagram of communication channel protocol stacks provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of an edge server switching device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0032] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0033] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0034] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

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

[0036] To facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish the same or similar items with essentially the same function and effect. Those skilled in the art can understand that the terms "first" and "second" are not intended to limit the quantity or execution order.

[0037] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0038] With the rapid development of intelligent connected vehicles, vehicle remote control technology has become one of the core functions of intelligent vehicles.

[0039] Current vehicle remote control systems mainly adopt the following technical solutions: (1) Cloud-based centralized control: Remote control commands are transmitted to the cloud server via the mobile network and then forwarded to the vehicle by the cloud server.

[0040] (2) Edge server-assisted control: Some manufacturers have begun to adopt edge computing technology and deploy edge servers close to the vehicle to shorten the transmission distance.

[0041] (3) Simple switching mechanism: At present, edge switching technology mostly adopts a passive switching method, that is, switching is only performed when the current edge server fails or the load is too high, which lacks foresight.

[0042] However, the current solution has the following problems: (1) Single dimension of edge server selection: Only considering single factors such as distance or load, without comprehensively considering multiple dimensions such as network quality, historical stability, and cost, resulting in the selection of edge servers that are not optimal.

[0043] (2) Delayed handover timing: The passive trigger handover mechanism is adopted. The handover is only performed when the service quality is detected to be degraded. There is a risk of service interruption during the handover process, and the handover delay is large (usually >100ms).

[0044] (3) Lack of predictive ability: The vehicle's trajectory is not considered, and the target edge node cannot be pre-connected, resulting in frequent disconnection and reconnection during vehicle movement, which affects the continuity of remote control.

[0045] (4) Imperfect seamless switching mechanism: When switching edge servers, no effective state synchronization mechanism is established, resulting in the loss or repeated execution of control commands during the switching process.

[0046] Based on this, this application provides an edge server switching method. By acquiring vehicle driving data and edge server status in real time, the method predicts vehicle trajectory and pre-selects target servers to establish connections, achieving seamless service migration when conditions are met. This effectively overcomes the limitations of existing passive switching and single evaluation dimensions, solving problems such as switching lag, easy service interruption, and difficulty in adapting to high-speed movement, and comprehensively ensuring the real-time performance, continuity, and reliability of remote vehicle control.

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

[0048] The edge server switching method provided in this application can be applied to electronic devices. These electronic devices can be servers, such as a server cluster consisting of multiple servers, a single server, a computer, or a processor or processing chip within a server or computer. For example, the electronic device can also be a terminal, such as a mobile phone, tablet computer, wearable device, in-vehicle device, laptop computer, or ultra-mobile personal computer. Mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), etc. It should be noted that the embodiments of this application do not limit the specific form of the electronic device.

[0049] Figure 1 An architecture diagram of a remote control system provided in this application embodiment is shown below. Figure 1 As shown, the remote control system 100 includes: The remote control terminal layer 110 provides a user interface for interacting with the system, used to send control commands and view vehicle status. It may include smartphone applications, in-vehicle tablet control terminals, and computer terminals. It establishes communication with the edge computing layer 120 via 4G or 5G mobile communication technology.

[0050] Edge computing layer 120 is the core layer of the system, deploying edge servers with computing capabilities to handle tasks with extremely high real-time requirements. Edge server A, currently providing remote control services for vehicles, can be considered a specific implementation of the aforementioned electronic devices. It includes: Vehicle status acquisition module: Receives data reported by vehicles in real time.

[0051] Edge server management module: monitors its own load and resource status.

[0052] Scoring Calculation Module: Calculates a comprehensive score based on its own status and network quality.

[0053] Trajectory prediction module: Predicts the future driving route based on the vehicle's current position and speed.

[0054] Candidate Management Module: Based on predicted trajectories, it identifies and evaluates the next possible best edge server in advance.

[0055] Switching control module: When certain conditions are met, it enables the smooth migration of the main service.

[0056] Communication module: Responsible for data interaction with vehicles and other edge servers.

[0057] Edge server B, as the target edge server, has already established a context connection with the vehicle in advance, but has not yet officially taken over control. Its internal module structure is the same as server A, and it is in a hot standby state. Edge server C is a potential server located further away from the predicted trajectory. The system will continuously monitor and evaluate it as a backup resource pool for future use.

[0058] Network communication layer 130 is the data transmission channel, connecting the vehicle and the edge server. This layer includes: 5G base stations (gNodeB, gNB): provide high-bandwidth, low-latency wireless access services and are the first hop for communication between vehicles and edge servers.

[0059] Roadside unit (RSU): In conjunction with C-V2X technology, it provides vehicle-road cooperative communication capabilities, enhancing the vehicle's perception of the surrounding environment and communication stability.

[0060] Core network (5G Core, 5GC): The core network infrastructure of the operator, responsible for data routing, session management and user authentication, and directing data flow to the correct edge server.

[0061] Cellular Vehicle-to-Everything (C-V2X) / 5G Network: This refers to the specific communication technology standards used in this layer to ensure low latency and high reliability transmission.

[0062] The vehicle terminal layer 140 is the physical foundation of the system, responsible for data acquisition, command execution, and basic in-vehicle communication, including: Telematics Box (T-BOX): As the vehicle's network access point, it is responsible for sending data from inside the vehicle (such as location, speed, and sensor data) to the external network and receiving control commands from the cloud.

[0063] Vehicle control unit (VCU): The core of vehicle processing, responsible for parsing received remote control commands and converting them into specific vehicle action signals.

[0064] Sensors (GPS / radar / camera): responsible for sensing the vehicle's real-time status (position, speed) and surrounding environment information, providing raw data support for remote control and trajectory prediction.

[0065] Actuator (Brake / Steering / Drive): The main body that executes commands, directly executes the commands issued by the VCU, and completes physical actions such as braking, turning, and acceleration.

[0066] In-vehicle network: An internal communication bus that connects all the above-mentioned in-vehicle hardware.

[0067] Figure 2 This is a flowchart illustrating an edge server switching method provided in an embodiment of this application. Figure 2 As shown, the edge server switching method provided in this application can be implemented by the aforementioned electronic device, specifically including S201~S204.

[0068] S201. Obtain vehicle driving data and server information of multiple edge servers.

[0069] The high-speed mobility of vehicles means that their network environment is dynamically changing, while the resources of edge servers are also limited. Only by obtaining information about the vehicles and edge servers can the equipment make reasonable judgments and avoid blind switching or switching failures.

[0070] Among them, driving data refers to real-time parameters describing the vehicle's motion state, including: the vehicle's position (such as latitude and longitude coordinates), speed, and heading angle (such as the angle at which the vehicle is facing); server information refers to data describing the service capabilities of edge nodes, including: the spatiotemporal correlation characteristics of edge servers (such as the signal coverage relationship between the server and a specific geographical location, historical connection quality, etc.) and load status (such as current processing utilization, memory usage, bandwidth usage, etc.); among multiple edge servers, there is the current edge server that is currently providing services to the vehicle.

[0071] Specifically, the vehicle obtains its location via GPS / BeiDou module, acquires its speed and heading angle via wheel speed sensor or inertial measurement unit, and reports it to electronic equipment via T-BOX at a fixed frequency (e.g., 20Hz). The current edge server or core network elements periodically send heartbeat packets or status query requests to multiple neighboring edge servers to collect their load rates and signal coverage maps. The vehicle's driving data and the server information of the edge servers are aggregated into a decision center (which can be the current edge server or an independent control node).

[0072] S202. Based on driving data, predict the vehicle's driving trajectory to obtain the predicted trajectory.

[0073] By predicting trajectories, the device can know in advance which areas the vehicle will pass through in the next few seconds or even tens of seconds, thereby locking onto the target edge server in advance and achieving seamless switching.

[0074] The predicted trajectory is a virtual path of the vehicle over a future period of time, calculated based on the current vehicle's motion state. It typically consists of a series of coordinate points with timestamps.

[0075] Specifically, Kalman filtering or a simple uniform / uniformly accelerated motion model can be used to calculate the position sequence within the next T seconds (usually 5-10 seconds) based on the current position, speed, and heading angle. The calculated coordinates are then projected onto a map, and the predicted path is corrected by combining road topology (such as lane lines and turning restrictions) to ensure that the predicted trajectory conforms to the actual road direction.

[0076] In one implementation, historical trajectory sequences can be input into a large model to output a future trajectory probability distribution that better matches the driver's habits, thereby improving the accuracy of trajectory prediction.

[0077] S203. Based on server information and driving data, determine the target edge server that meets the preset conditions from multiple edge servers.

[0078] After determining the predicted trajectory, it is necessary to further identify the edge servers that can provide services. Therefore, it is necessary to select the optimal solution from multiple candidate edge servers to ensure service quality and continuity.

[0079] The service range of the target edge server covers the predicted trajectory.

[0080] Specifically, the predicted trajectory is overlaid with a "coverage map" of multiple edge servers for analysis, filtering out a set of edge servers whose trajectory landing points are all within the coverage area. Then, candidate edge servers are scored, with their scores determined by factors such as average signal strength on the predicted trajectory, current remaining computing resources, and the physical distance or network hop count between the vehicle and the edge server. Finally, the server with the highest overall score is selected as the target edge server. If the current server still meets the criteria and has the highest score, the status quo is maintained; otherwise, a new server is marked as the target edge server.

[0081] In one implementation, multiple servers with the highest overall scores can be marked as candidate target edge servers, and then the target edge server can be selected from them according to actual needs, such as selecting the server closest to the vehicle or the server with the lowest load.

[0082] In another implementation, S203 can be specifically implemented through S2031-S2033: S2031. Map server information and driving data into multiple evaluation dimensions.

[0083] Each evaluation dimension has a corresponding evaluation weight.

[0084] The raw driving data and server information are heterogeneous and cannot be directly compared. Therefore, a standardized evaluation model needs to be established. By introducing weights, strategies can be flexibly adjusted according to business needs—for example, assigning higher weight to signal stability in high-speed scenarios and higher weight to server load in congested scenarios, thereby achieving differentiated service quality assurance.

[0085] Specifically, key features are extracted from the raw data. For example, the vehicle's movement vector relative to each server is calculated from GPS data; server processor utilization and memory usage are extracted from heartbeat packets; and data with different dimensions are mapped to a unified range (such as 0-1 or 0-100). For example, the range transformation method is used to convert signal strength (-120dBm to -50dBm) into a fraction of 0-100. Initial weights are preset using the analytic hierarchy process or expert experience, or machine learning models are used to dynamically adjust weights based on historical handover success rates.

[0086] For example, the evaluation model may include the following rating factors, each of which corresponds to an evaluation dimension: (1) Network delay factor: Network delay is evaluated by measuring the round trip time (RTT) in real time. The calculation formula is: Score_delay=(RTT_max-RTT_current) / RTT_max w1(t), where Score_delay is the network latency score, RTT_max is the maximum tolerable latency, RTT_current is the current network latency, and w1(t) is the network latency weighting coefficient.

[0087] (2) Server load factor: Evaluate the CPU, memory, and bandwidth utilization of the edge server: Score_load=(1-CPU_usage) w2(t)+(1-Memory_usage) w3(t)+(1-Bandwidth_usage) w4(t), where Score_load is the server load score, CPU_usage is the current CPU load rate, w2(t) is the CPU load weight, Memory_usage is the memory usage rate, w3(t) is the memory weight, Bandwidth_usage is the bandwidth usage rate, and w4(t) is the bandwidth weight.

[0088] (3) Geographic distance factor: Calculate the physical distance between the vehicle and the edge server: Score_distance=(D_max-D_current) / D_max w5(t) represents distance weights: Score_distance, D_max, D_current, and w5(t) represents geographic distance weights.

[0089] (4) Historical stability factor: Based on historical data, the availability and packet loss rate of the edge server are statistically analyzed. Score_stability=Availability (1-Packet_loss_rate) w6(t) represents the historical stability score, Availability represents the percentage of time the edge server is available, Packet_loss_rate represents the packet loss rate, and w6(t) represents the historical stability weight.

[0090] (5) Cost factor: Considering bandwidth costs and computing costs: Score_cost=(Cost_max-Cost_current) / Cost_max w7(t) represents the cost score, Cost_max represents the maximum acceptable communication cost, Cost_current represents the current communication cost, and w7(t) represents the communication cost weight.

[0091] Overall score calculation formula: Total_Score = Score_delay + Score_load + Score_distance + Score_stability + Score_cost. Total_Score is the overall evaluation score.

[0092] Table 1 shows the scoring results provided in the embodiments of this application. Please refer to Table 1.

[0093] Table 1

[0094] S2032. For each edge server, determine the evaluation score based on multiple evaluation dimensions and corresponding evaluation weights.

[0095] Since there may be multiple candidate servers around the vehicle, and each server has its own advantages and disadvantages in different dimensions (for example, server A has a good signal but high load, while server B has low load but is far away), a comprehensive score needs to be calculated by weighting to make a horizontal comparison.

[0096] The evaluation score represents a quantitative value of a given edge server's overall service capability for the current vehicle at the current moment. The higher the score, the more suitable the server is as a next-hop service node.

[0097] Specifically, the score for each edge server is calculated using linear weighting, and a penalty function can be set for certain key metrics (such as latency). If the latency exceeds a threshold, the total score will be significantly reduced even if other dimensions score highly, in order to avoid selecting nodes that are "theoretically high-scoring but practically unusable".

[0098] S2033. Based on the evaluation score of each edge server, determine the target edge server.

[0099] Among them, the evaluation score of the target edge server is greater than or equal to the first preset score.

[0100] Simply selecting the highest-scoring edge server may not meet actual service demands in some situations. If all servers have low scores, forcibly switching to the relatively best server could still lead to service interruptions. Therefore, a first preset score is introduced as the admission threshold, ensuring that a switch is only performed when the target edge server truly has the service capability, thus avoiding the risks associated with "selecting the best from the worst."

[0101] Specifically, all candidate servers are sorted from highest to lowest score. If the highest score is greater than or equal to the first preset score, the server is selected as the target edge server; if the highest score is less than the first preset score, it is determined that there is no suitable target, and the current connection can be maintained or a degradation strategy can be triggered.

[0102] In addition, to prevent frequent switching caused by score fluctuations around the threshold, a time window or hysteresis comparator can be used to confirm the final result.

[0103] Based on the implementation methods of S2031-S2033 described above, by mapping server information and driving data to multiple evaluation dimensions and assigning corresponding weights, a quantitative evaluation of the comprehensive performance of edge servers is achieved, effectively overcoming the limitations of traditional solutions that rely solely on a single indicator for decision-making. Furthermore, for each candidate edge server, a comprehensive evaluation score is calculated by combining multi-dimensional indicators and their weights, enabling a comprehensive and accurate measurement of the overall service capabilities of each node in terms of spatiotemporal correlation, network quality, and resource status. Finally, by setting a first preset score as a screening threshold, only edge servers that meet the evaluation score are selected as target nodes, ensuring that the ultimately selected servers meet the current and future service needs of the vehicle in all key indicators. This significantly improves the rationality of edge server selection and further guarantees low latency and high reliability during vehicle remote control.

[0104] The operating environment of vehicles and network conditions are highly dynamic. Fixed weights can lead to incorrect decisions in certain scenarios. For example, when a vehicle is cornering at high speed, link stability is more critical than server load; while when a vehicle is stationary waiting at a traffic light and surrounding servers are congested, computational resource reserves may be more important than signal strength in ensuring uninterrupted service. Therefore, in one implementation, the method also includes: S2034. When driving data and / or server information meet the weight adjustment conditions, the evaluation weights corresponding to multiple evaluation dimensions shall be adjusted.

[0105] The weight adjustment condition refers to the preset trigger threshold or logical rule. It can be a sudden change in a single indicator (such as a vehicle speed suddenly exceeding 100km / h), or the state of a combination of indicators (such as the current server load exceeding 80% and the signal fluctuation rate being greater than 10%).

[0106] Specifically, multiple sets of trigger rules are pre-set within the electronic device. For example: Rule A: If the vehicle speed is >80km / h, it is judged as a "high-speed scenario".

[0107] Rule B: If the current server CPU utilization is >90%, it is judged as a "high load scenario".

[0108] Rule C: If the predicted trajectory indicates that the vehicle is about to enter a tunnel or an obstructed area, it is classified as a "weak signal risk scenario". Electronic devices monitor driving data and server status at high frequency (e.g., multiple times per second). Once any of the above rules is matched, the weight adjustment process is activated.

[0109] Furthermore, it should be noted that S2034 can be executed before S2031 or after S2033. This application does not limit the timing of its execution. The evaluation weights corresponding to multiple evaluation dimensions can be adjusted when the weight adjustment conditions are met.

[0110] Based on the implementation of S2034 described above, by dynamically adjusting the weights of the evaluation dimensions when driving data or server information meets specific conditions, the edge server selection strategy can adaptively optimize according to changes in vehicle driving status and network environment. This dynamic weight adjustment mechanism effectively overcomes the problem of poor adaptability of fixed weight strategies in complex and ever-changing scenarios, making the determination of target edge servers more aligned with actual operational needs, further improving the flexibility and rationality of switching decisions, and ensuring high-quality service continuity under different operating conditions.

[0111] Furthermore, the spatiotemporal correlation features include the network latency, packet loss rate, and server location of the edge server, while the load status includes the communication cost and load occupancy of the edge server. To make the scoring more accurate and comprehensive, simple signal strength or load is insufficient to describe complex edge computing environments. Introducing other metrics can further improve the accuracy and comprehensiveness of the scoring. These metrics together form a three-dimensional evaluation coordinate system.

[0112] Therefore, the weight adjustment conditions in S2034 above may specifically include: network latency greater than a preset latency; and / or, packet loss rate greater than a preset packet loss rate; and / or, the distance between the edge server and the vehicle greater than a preset distance; and / or, The vehicle speed is greater than the preset speed; and / or, the communication cost is greater than the preset cost; and / or, the load occupancy rate is greater than the preset load occupancy rate.

[0113] Network latency refers to the time required for data packets to travel from the vehicle to the edge server and back, directly impacting the real-time performance of remote control. Packet loss rate refers to the proportion of data packets lost during transmission; a high packet loss rate can lead to lost control commands or video stuttering. Server location refers to the physical coordinates of the edge server, used to calculate the straight-line or path distance to the vehicle. Communication cost refers to the economic overhead or resource consumption incurred by data transmission (such as cross-carrier settlement fees, high costs of satellite links, etc.). Load utilization refers to the percentage of server CPU, memory, or bandwidth used, reflecting its ability to handle new tasks.

[0114] Based on these metrics, the specific triggering conditions for weight adjustment were further refined. Key indicators such as network latency, packet loss rate, server location, vehicle speed, communication cost, and load occupancy were set as thresholds, enabling the implementation entity to accurately perceive abnormal fluctuations in vehicle driving status and the edge network environment. When any of the above indicators exceeds the preset range, the weight adjustment mechanism is triggered. This dynamic response mechanism based on multi-source data thresholds not only enhances the adaptability of the edge server switching strategy but also ensures that, under complex and ever-changing actual operating conditions, the implementation entity can flexibly balance multiple requirements such as real-time performance, reliability, and economy, thereby effectively improving the rationality of target edge server selection and the stability of overall service.

[0115] Furthermore, based on the above indicators, and assuming the sum of the weights for each dimension is 1, S2034 can be implemented in the following way: S2034a. When the network delay is greater than the preset delay, increase the evaluation weight of network delay and decrease the evaluation weight of distance and communication cost.

[0116] When latency exceeds a threshold, it indicates that the current communication link is approaching its real-time limit. At this point, "low latency" should be the primary objective. Even if the target server is slightly farther away or the communication cost is slightly higher, it is necessary to prioritize ensuring the timeliness of control commands. Distance and cost are secondary factors that can be compromised in this scenario.

[0117] For example, the delay weight increases from 0.25 to 0.4 (+0.15), the distance decreases from 0.15 to 0.075 (-0.075), and the cost decreases from 0.1 to 0.025 (-0.075).

[0118] S2034b: When the packet loss rate is greater than the preset packet loss rate, increase the evaluation weight of the packet loss rate and reduce the evaluation weight of distance and communication cost.

[0119] A high packet loss rate means a severe decrease in the reliability of data transmission, and control commands may be lost, posing a fatal threat to vehicle safety. In this case, it is necessary to prioritize links with low packet loss rates, even if those links are farther away or more expensive. The logic is similar to latency degradation; both prioritize ensuring communication quality.

[0120] For example, the packet loss rate weighting increases from 0.2 to 0.35 (+0.15), while the distance and cost each decrease by 0.075.

[0121] S2034c: When the distance between the edge server and the vehicle is greater than the preset distance, increase the evaluation weight of distance and reduce the evaluation weight of communication cost.

[0122] Excessive distance usually means increased signal attenuation and propagation delay. In such cases, distance needs to be given more weight, and a closer server should be chosen.

[0123] For example, the distance weight increases from 0.15 to 0.25 (+0.1), and the cost decreases from 0.1 to 0 (-0.1).

[0124] S2034d: When the vehicle speed is greater than the preset speed, increase the evaluation weight of speed and decrease the evaluation weight of communication cost.

[0125] High-speed travel means vehicles will rapidly traverse the current server's coverage area, resulting in extremely short switching windows. In this scenario, speed becomes the primary focus, prioritizing servers with large coverage areas and low switching frequencies to mitigate the risks associated with frequent switching. Communication costs are no longer a primary concern.

[0126] For example, the speed weight increases from 0.1 to 0.2 (+0.1), while the cost decreases from 0.1 to 0 (-0.1).

[0127] S2034e: When the communication cost is greater than the preset cost, increase the evaluation weight of communication cost and reduce the evaluation weight of network latency, packet loss rate and distance.

[0128] When communication costs are too high (such as when vehicles roam to expensive areas), it is necessary to control costs as much as possible while ensuring basic service quality. Therefore, it is necessary to reduce stringent requirements on latency, packet loss rate, and distance, and allow for a certain degree of performance compromise in exchange for controllable costs.

[0129] For example, increasing the cost weight from 0.1 to 0.3 (+0.2) reduces latency, packet loss rate, and distance by approximately 0.067.

[0130] S2034f: When the load utilization rate is greater than the preset utilization rate, increase the evaluation weight of the load utilization rate and reduce the evaluation weight of the communication cost.

[0131] When a server is overloaded and its capacity to handle new tasks is nearing its limit, continuing to assign tasks to it may cause service crashes. In this case, it is necessary to prioritize servers with lower loads, even if those servers have slightly higher communication costs. Cost is a compromise in this scenario.

[0132] For example, the load weight increases from 0.2 to 0.35 (+0.15), and the cost decreases from 0.1 to -0.05 (in practice, it decreases to 0, and the original cost dimension weight is proportionally distributed to other dimensions).

[0133] As another example, this application also provides different weight adjustment modes for different scenarios, including: (1) Network quality sensitive mode: Triggering conditions: Current network latency RTT_current > RTT_threshold (preset latency) or packet loss rate Packet_loss_rate > PLR_threshold (preset packet loss rate); Weight adjustment: increase w1(t) by 30%~50%, decrease w5(t) and w7(t); Purpose: Prioritize low-latency edge servers to ensure communication quality.

[0134] (2) High load avoidance mode: Triggering conditions: Current edge server CPU utilization (CPU_usage) > CPU_threshold (preset utilization) or current memory utilization (Memory_usage) > MEM_threshold (preset memory utilization); Weight adjustment: increase w2(t), w3(t), and w4(t) by 40%~60%, and decrease w5(t); Purpose: Prioritize edge servers with low load to avoid congestion.

[0135] (3) High-speed movement mode: Triggering condition: Current vehicle speed V_vehicle>V_threshold (preset speed such as 80km / h); Weight adjustment: increase w5(t) by 50%~70% and decrease w7(t); Purpose: Prioritize the selection of the nearest edge server to reduce the switching frequency.

[0136] (4) Cost optimization mode: Triggering condition: Current communication cost Cost_current>Cost_threshold (preset cost); Weight adjustment: increase w7(t) by 40%~60%, and decrease w1(t) and w5(t); Purpose: Reduce communication cost while ensuring basic communication quality.

[0137] In addition, an exponentially weighted moving average is used to avoid drastic weight fluctuations during weight adjustment; at the same time, reinforcement learning is used to optimize the weight adjustment strategy based on historical switching results.

[0138] Based on the implementation methods of S2034a-S2034f described above, under the constraint that the sum of weights is always 1, specific and differentiated weight adjustment directions are specified for different abnormal scenarios such as network latency, packet loss rate, distance, speed, communication cost, and load occupancy. This allows the evaluation process to adaptively reconstruct according to actual operating conditions. This weight redistribution mechanism not only ensures the normalization of the weights of each evaluation dimension but also achieves precise tilting of the evaluation strategy under different abnormal scenarios. This ensures that the selection of target edge servers always aligns with the most urgent service needs, further improving the intelligence level of switching decisions and the robustness of the overall system.

[0139] S204. Instruct the vehicle to establish a communication connection with the target edge server, and when the driving data and / or the server information of the current edge server meet the switching conditions, switch to the target edge server to provide services to the vehicle.

[0140] Establishing a connection in advance can reduce handshake latency during handover; setting handover conditions can prevent frequent and repeated handovers or wasting resources when handover is not needed. Control is only formally transferred when a handover is truly necessary.

[0141] The switching conditions are the thresholds that trigger the formal business migration. For example: a vehicle enters the target server's main coverage area, the current server's signal is below a threshold, or a prediction indicates that the current server will be unavailable within the next 5 seconds.

[0142] Specifically, the current edge server notifies the target edge server to reserve resources. Simultaneously, it instructs the vehicle terminal (T-BOX) to establish an underlying link with the target server via network-side signaling. The device continuously monitors the vehicle and the current server to ensure that handover conditions are met, such as whether the vehicle's actual location has entered the target server's optimal service area and whether the current edge server's latency exceeds a threshold. Once the handover conditions are met, the vehicle data stream is changed from the current edge server's forwarding path to the target edge server's path. The vehicle's real-time control status (such as braking force and steering wheel angle) is synchronized from the current edge server to the target edge server, and then the service connection with the current server is disconnected, completing the handover.

[0143] For example, a Make-Before-Break mechanism is used during the handover process to ensure that the service is not interrupted during the handover; the target handover latency is <50ms.

[0144] Meanwhile, the following methods further reduce communication latency: (1) Protocol optimization: The transmission control protocol (TCP) is replaced by the quick UDP internet connections (QUIC) protocol to reduce connection establishment latency; 0-RTT handshake is supported to achieve fast connection recovery.

[0145] (2) Data compression: Differential compression is performed on control commands and vehicle status data; an adaptive compression algorithm is adopted to dynamically adjust the compression rate according to the network conditions.

[0146] (3) Priority scheduling: Control commands are classified by priority: emergency (braking, steering), high priority (acceleration, gear shifting), and normal (air conditioning, windows); high priority commands are transmitted first, and low priority data channels can be preempted.

[0147] Figure 3 This is a comparative diagram of the communication channel protocol stack provided in the embodiments of this application, as shown below. Figure 3 As shown.

[0148] Both the traditional TCP scheme and the QUIC scheme of this application include: application layer, transport layer, security layer, network layer, data link layer, and physical layer. The difference lies in the fact that the scheme of this application improves each layer to reduce communication latency, for example: At the application layer, traditional solutions use Hypertext Transfer Protocol (HTTP) 1.1, while this application uses a custom remote control protocol, as well as differential compression and priority marking.

[0149] At the transport layer, the TCP protocol requires a three-way handshake, and the connection establishment delay is 100-200ms. In this application, the QUIC protocol implements a 0-RTT handshake, supports multiplexing and forward error correction (FEC), and avoids head-of-line blocking.

[0150] Transport layer security (TLS) protocols require two handshakes, adding an extra 100-200ms of latency. This application uses TLS 1.3, which requires only a 1-RTT handshake and supports 0-RTT recovery, significantly reducing the overhead of the security handshake.

[0151] At the network layer, traditional solutions use Internet Protocol version 6 (IPv6) / Internet Protocol (IP). This application also uses IP / IPv6, but supports connection migration, such as maintaining an uninterrupted connection when the IP address changes (e.g., when a vehicle moves).

[0152] At the data link layer, traditional solutions use Ethernet / 5G to handle data frame transmission over the physical medium, while the solution in this application uses 5G Multi-Radio (MR) / Cellular Vehicle-to-Everything (C-V2X) to support low-latency scheduling and priority quality of service (QoS), and is specifically optimized for vehicle-to-everything (V2X) networks.

[0153] At the physical layer, traditional solutions use fiber optics / wireless to handle the physical transmission of electrical or optical signals, while the solution in this application uses 5G millimeter wave / sub-6GHz bands (Sub-6 Gigahertz, Sub-6GHz) to provide high bandwidth and low latency physical transmission capabilities.

[0154] The total establishment latency of the traditional solution is 200–400ms, with the main bottleneck being the TCP three-way handshake plus the TLS two-way handshake; while the total establishment latency of this application is 0–50ms, which is 87.5% lower than that of the traditional solution.

[0155] Table 2 is a comparison table of communication establishment performance between the proposed solution and the traditional solution. See Table 2.

[0156] Table 2

[0157] Table 3 shows the switching timing flow of a seamless edge switching provided in the embodiments of this application. Please refer to Table 3.

[0158] Table 3

[0159] To make the switching process more explicit, in one implementation, the switching conditions may specifically include the vehicle leaving the coverage area of ​​the current edge server within a preset time; and / or, the evaluation score of the current edge server being less than or equal to a second preset score.

[0160] If a vehicle is about to leave the current server's signal coverage area and a handover has not yet been initiated, the vehicle will face the risk of communication interruption. Therefore, introducing a "preset time" instead of "immediate departure" as the judgment criterion is to allow sufficient handover preparation time to achieve a "seamless handover".

[0161] The preset time is a lead time threshold, such as 3 seconds, 5 seconds, or 10 seconds. If it is predicted that a vehicle will leave the coverage area within T seconds, a handover is triggered instead of waiting until it actually leaves. The coverage area refers to the geographical area where the current edge server can provide effective service, usually defined by the signal strength contour lines of the base station.

[0162] Specifically, the electronic device combines the vehicle's predicted trajectory with the current edge server's coverage map to calculate the expected time when the vehicle will leave the coverage area; it then compares the difference between the expected time of leaving the coverage area and the current time with a preset time. If the difference is less than or equal to the preset time, the switching condition is met.

[0163] In another scenario, the vehicle may not have left the coverage area, but the current server's service quality has severely degraded. In this case, even if the vehicle is still within the coverage area, continuing to use the server will seriously impact user experience and even jeopardize security. This condition ensures proactive switching when "quality deteriorates," rather than passively waiting for the vehicle to leave.

[0164] Specifically, the electronic device re-evaluates the current edge server at fixed intervals (e.g., every 500ms); the latest evaluation score is compared with a second preset score. If the score is less than or equal to the second preset score, the current edge server is deemed unqualified, and a switching operation is performed to migrate the vehicle's service to a previously pre-selected target edge server.

[0165] Based on the above implementation, by setting specific switching trigger conditions, a clear and quantifiable decision-making basis is provided for edge server switching, effectively avoiding the problems of ambiguous switching timing or reliance on manual intervention in traditional solutions. Specifically, using whether the vehicle leaves the current edge server's coverage area within a preset time as a switching condition allows electronic devices to predict service boundaries in advance based on the vehicle's location and movement trends, proactively triggering a switch before the vehicle leaves the coverage area, thus preventing service interruptions due to signal attenuation or disconnection. Using whether the current edge server's evaluation score falls below a second preset score as another switching condition allows electronic devices to monitor the overall performance status of the current service node in real time. Once key indicators such as network quality and load level deteriorate to an unacceptable level, the switching process can be initiated promptly, preventing the vehicle from continuing to rely on a degraded server. These two conditions complement each other, covering both spatial coverage issues caused by vehicle mobility and scenarios of server performance degradation, jointly ensuring the accuracy and timeliness of switching timing, further improving the continuity and reliability of vehicle remote control services.

[0166] Based on the implementation of S201-S204 described above, the vehicle's current motion state and the real-time resource distribution of the edge network are first clarified by acquiring driving data such as the vehicle's position, speed, and heading angle, as well as the spatiotemporal correlation characteristics and load status of the edge servers, providing data support for subsequent decision-making. On this basis, the vehicle's trajectory is predicted based on the driving data, thus enabling advance knowledge of the vehicle's future spatial location and effectively overcoming the handover lag caused by the lack of mobility prediction in traditional solutions. Subsequently, combining the predicted trajectory and server information, target edge servers whose service range can cover the predicted trajectory are selected from multiple edge servers, ensuring the service continuity and adaptability of candidate nodes along the vehicle's future driving path. Finally, the vehicle is instructed to establish a communication connection with the target edge server in advance, and complete the service handover when the handover conditions are met. This pre-connection mechanism effectively avoids communication interruptions and service delays that may occur during traditional passive handover, thereby significantly improving the smoothness and reliability of edge server handover and ensuring the real-time and continuous remote control of the vehicle during movement.

[0167] In one implementation, to achieve seamless takeover of vehicle services by the edge server, S204 can be implemented through the following steps: S2041. Synchronize the vehicle's current session state to the target edge server.

[0168] The vehicle and the current edge server may be conducting real-time business (such as remote driving control command streaming, high-definition video transmission, sensor data uploading, etc.). If the old connection is directly disconnected and a new connection is established without transferring session state, the target server will be in a blank state and unable to resume previous business, resulting in service interruption. Therefore, session state synchronization is a core prerequisite for achieving seamless switching.

[0169] The current session state includes, but is not limited to: vehicle authentication information, established communication protocol context (such as TCP / UDP session parameters), sequence number of data streams being transmitted, queue of unacknowledged instructions, cached sensor data, and service subscription relationships.

[0170] Specifically, after receiving the switchover instruction, the current edge server takes a snapshot of the key state of the current session and sends the session state data to the target edge server through the internal high-speed link between edge servers (such as the Xn interface or a dedicated backhaul link). After receiving the data, the target edge server reconstructs the session context based on the snapshot, so that it is in the same "ready" state as the current server and can seamlessly take over subsequent services.

[0171] S2042. Route the communication traffic between the vehicle and the current edge server to the target edge server.

[0172] After the session state is synchronized, the actual data stream "pipeline" needs to be switched from the current server to the target server. This step is the actual switching action—from then on, all uplink data sent by the vehicle (such as video streams and sensor data) and all downlink data sent by the target server (such as control commands) will be transmitted through the new link.

[0173] Specifically, the core network updates data forwarding rules (such as the N3 tunnel endpoint in 5G) to forward downlink traffic destined for the vehicle from the current edge server to the target edge server; the vehicle side (or onboard communication module) updates the destination IP address / port of uplink data and sends subsequent uplink traffic to the target edge server; in the initial stage of the handover, traffic can be sent to both the old and new servers simultaneously to ensure that no data packets are lost within the millisecond window of the routing switch.

[0174] S2043, Instructs the vehicle to release its communication connection with the current edge server.

[0175] After the handover is complete, the connection between the vehicle and the current edge server becomes a redundant resource. Failure to release this connection promptly may lead to wasted resources on the vehicle's communication module (e.g., maintaining multiple TCP connections consumes memory and power); wasted resources on the current server side (e.g., maintaining invalid session contexts consumes CPU and memory); and subsequent routing confusion (e.g., receiving delayed packets on the old link causing data duplication). Therefore, it is necessary to release the connection with the current edge server after the handover is complete.

[0176] Specifically, the target edge server (or the current edge server) sends a connection release command to the vehicle, informing it that the old connection is no longer needed. Upon receiving the command, the vehicle disconnects from the current edge server according to the communication protocol. After detecting the connection break, the current edge server releases all resources allocated to the vehicle (such as computing resources, cache, session entries, etc.) and completes the cleanup. After the handover is complete, a handover completion notification is sent to the remote control terminal.

[0177] Based on the implementation methods of S2041-S2043 described above, a smooth and seamless edge server handover process is achieved through the orderly steps of session state synchronization, traffic routing switching, and releasing the old connection. First, before the handover, the vehicle's current session state is synchronized to the target edge server, enabling the target server to fully inherit the vehicle's control context information and avoiding the loss or duplicate execution of control commands caused by session reconstruction during the handover. Then, communication traffic is routed from the current edge server to the target edge server, ensuring that the control data flow is directed to the new node before the handover is completed on the vehicle side, thus achieving data path continuity. Finally, after traffic routing is completed, the vehicle is instructed to release the connection with the current edge server. This "connect first, then disconnect" mechanism effectively eliminates the communication gap caused by disconnecting the old connection and then establishing a new connection during traditional handover processes. This ensures uninterrupted transmission of vehicle remote control commands during the handover process, significantly reducing handover latency and packet loss risk, and further improving the continuity and reliability of the vehicle remote control service.

[0178] This application embodiment can divide the following device into functional modules based on the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0179] In some embodiments, this application also provides an edge server switching device. The device may include one or more functional modules for implementing the methods described in the above embodiments. For example, Figure 4This is a schematic diagram of the structure of an edge server switching device 400 provided in an embodiment of this application. Figure 4 As shown, the edge server switching device 400 includes: The acquisition module 410 is used to acquire vehicle driving data and server information of multiple edge servers; the driving data includes the vehicle's position, speed and heading angle, and the server information includes the spatiotemporal correlation characteristics and load status of the edge servers, including the current edge server that is currently providing services to the vehicle. The processing module 420 is used to predict the vehicle's trajectory based on driving data to obtain the predicted trajectory; The processing module 420 is also used to determine the target edge server that meets the preset conditions from multiple edge servers based on server information and driving data; the service range of the target edge server covers the predicted trajectory. The control module 430 is used to instruct the vehicle to establish a communication connection with the target edge server, and to switch to the target edge server to provide services to the vehicle when the driving data and / or the server information of the current edge server meet the switching conditions.

[0180] In one implementation, the processing module 420 is further configured to map server information and driving data into multiple evaluation dimensions; each evaluation dimension has a corresponding evaluation weight; for each edge server, an evaluation score of the edge server is determined based on the multiple evaluation dimensions and the corresponding evaluation weights; a target edge server is determined based on the evaluation score of each edge server; the evaluation score of the target edge server is greater than or equal to a first preset score.

[0181] In one implementation, the processing module 420 is further configured to adjust the evaluation weights corresponding to multiple evaluation dimensions when the driving data and / or server information meet the weight adjustment conditions.

[0182] In one implementation, the spatiotemporal correlation features include the network latency, packet loss rate, and server location of the edge server; the load status includes the communication cost and load occupancy rate of the edge server; and the weight adjustment conditions include: network latency greater than a preset latency; and / or, packet loss rate greater than a preset packet loss rate; and / or, distance between the edge server and the vehicle greater than a preset distance; and / or, vehicle speed greater than a preset speed; and / or, communication cost greater than a preset cost; and / or, load occupancy rate greater than a preset occupancy rate.

[0183] In one implementation, the sum of the weights of multiple evaluation dimensions is 1. The processing module 420 is further configured to: increase the evaluation weight of network latency and decrease the evaluation weight of distance and communication cost when the network latency is greater than a preset latency; and / or, increase the evaluation weight of packet loss rate and decrease the evaluation weight of distance and communication cost when the packet loss rate is greater than a preset packet loss rate; and / or, increase the evaluation weight of distance and decrease the evaluation weight of communication cost when the distance between the edge server and the vehicle is greater than a preset distance; and / or, increase the evaluation weight of speed and decrease the evaluation weight of communication cost when the vehicle speed is greater than a preset speed; and / or, increase the evaluation weight of communication cost and decrease the evaluation weight of network latency, packet loss rate, and distance when the communication cost is greater than a preset cost; and / or, increase the evaluation weight of load occupancy and decrease the evaluation weight of communication cost when the load occupancy rate is greater than a preset load occupancy rate.

[0184] In one implementation, the switching conditions include: the vehicle leaving the coverage area of ​​the current edge server within a preset time; and / or, the evaluation score of the current edge server being less than or equal to a second preset score.

[0185] In one implementation, the control module 430 is further configured to: synchronize the vehicle's current session state to the target edge server; route the communication traffic between the vehicle and the current edge server to the target edge server; and instruct the vehicle to release the communication connection with the current edge server.

[0186] When the methods of the above embodiments are implemented in hardware, this embodiment of the invention provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 5 As shown, the electronic device 500 includes: a processor 502, a communication interface 503, and a bus 504. Optionally, the electronic device 500 may also include a memory 501.

[0187] Processor 502 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 502 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 502 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0188] Communication interface 503 is used to connect to other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0189] The memory 501 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0190] In one possible implementation, the memory 501 can exist independently of the processor 502. The memory 501 can be connected to the processor 502 via a bus 504 and is used to store instructions or program code. When the processor 502 calls and executes the instructions or program code stored in the memory 501, it can implement the method provided in the embodiments of the present invention.

[0191] In another possible implementation, the memory 501 can also be integrated with the processor 502.

[0192] Bus 504 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 504 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0193] Through the above description of the embodiments, those skilled in the art can clearly 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 above device is divided into different functional modules to complete all or part of the functions described above.

[0194] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware. The program can be stored in the computer-readable storage medium, and when executed, it can include the processes of the above method embodiments. The computer-readable storage medium can be any of the foregoing embodiments or memory. The computer-readable storage medium can also be an external storage device of the above-described device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the above-described device. Further, the computer-readable storage medium can include both internal storage units and external storage devices of the above-described device. The computer-readable storage medium is used to store the above-described computer program and other programs and data required by the above-described device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0195] This application also provides a computer program product comprising a computer program that, when run on a computer, causes the computer to perform the methods provided in the above embodiments.

[0196] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for switching edge servers, characterized in that, The method includes: Acquire vehicle driving data and server information of multiple edge servers; the driving data includes the vehicle's position, speed, and heading angle, and the server information includes the spatiotemporal correlation characteristics and load status of the edge servers, including the current edge server currently providing services to the vehicle; Based on the driving data, the driving trajectory of the vehicle is predicted to obtain the predicted trajectory; Based on the server information and the driving data, a target edge server that meets preset conditions is determined from a plurality of edge servers; the service range of the target edge server covers the predicted trajectory. The system instructs the vehicle to establish a communication connection with the target edge server, and switches to the target edge server to provide services to the vehicle when the driving data and / or the server information of the current edge server meet the switching conditions.

2. The method according to claim 1, characterized in that, The step of determining a target edge server that meets preset conditions from a plurality of edge servers based on the server information includes: The server information and the driving data are mapped to multiple evaluation dimensions; each evaluation dimension has a corresponding evaluation weight. For each edge server, an evaluation score is determined based on the multiple evaluation dimensions and their corresponding evaluation weights. A target edge server is determined based on the evaluation score of each edge server; the evaluation score of the target edge server is greater than or equal to a first preset score.

3. The method according to claim 2, characterized in that, The method further includes: When the driving data and / or the server information meet the weight adjustment conditions, the evaluation weights corresponding to the multiple evaluation dimensions are adjusted.

4. The method according to claim 3, characterized in that, The spatiotemporal correlation features include the network latency, packet loss rate, and server location of the edge server; the load status includes the communication cost and load occupancy rate of the edge server; the weight adjustment conditions include: The network latency is greater than the preset latency; And / or, The packet loss rate is greater than the preset packet loss rate; And / or, The distance between the edge server and the vehicle is greater than a preset distance; And / or, The vehicle's speed is greater than the preset speed; And / or, The communication cost is greater than the preset cost; And / or, The load occupancy rate is greater than the preset occupancy rate.

5. The method according to claim 4, characterized in that, The sum of the weights of the multiple evaluation dimensions is 1, and the adjustment of the evaluation weights corresponding to the multiple evaluation dimensions includes: If the network latency is greater than a preset latency, increase the evaluation weight of the network latency and decrease the evaluation weight of the distance and the communication cost. And / or, If the packet loss rate is greater than the preset packet loss rate, increase the evaluation weight of the packet loss rate and decrease the evaluation weight of the distance and the communication cost. And / or, If the distance between the edge server and the vehicle is greater than a preset distance, the evaluation weight of the distance is increased and the evaluation weight of the communication cost is decreased. And / or, If the vehicle's speed is greater than a preset speed, increase the evaluation weight of the speed and decrease the evaluation weight of the communication cost. And / or, If the communication cost is greater than the preset cost, increase the evaluation weight of the communication cost and decrease the evaluation weights of the network latency, the packet loss rate, and the distance. And / or, If the load occupancy rate is greater than the preset occupancy rate, the evaluation weight of the load occupancy rate is increased, and the evaluation weight of the communication cost is reduced.

6. The method according to claim 2, characterized in that, The switching conditions include: The vehicle leaves the coverage area of ​​the current edge server within a preset time. And / or, The current edge server's evaluation score is less than or equal to the second preset score.

7. The method according to claim 1, characterized in that, The switching to the target edge server to provide services to the vehicle includes: Synchronize the current session state of the vehicle to the target edge server; The communication traffic between the vehicle and the current edge server is routed to the target edge server; Instruct the vehicle to release its communication connection with the current edge server.

8. An electronic device, characterized in that, It includes a processor and a memory, the processor being coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computer device to perform the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer-executable instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 7.

Images