Composite three-time handshake migration method for edge calculation

Abstract

The invention belongs to the technical field of mobile edge computing, and discloses a composite triple handshake migration method for edge computing, which comprises the following steps that: a source server implements task migration according to a task migration notification; the migration process is divided into three stages, namely a connection establishment stage, a data transmission stage and a connection release stage. For a source server, a mobile user and a target server, the source server originally needs to establish two independent connections with the mobile user and the target server respectively, and controls and manages message sequence numbers and retransmission respectively. According to the method, the process is improved, the number of connections is reduced to a three-party shared connection, the number of control messages is reduced in the connection establishment stage and the connection release stage, meanwhile, the mobile user clearly knows the condition of each state, and seamless migration of calculation tasks on the mobile user is facilitated. According to the method, the process is simple and convenient, connection management is simplified on the basis of maintaining reliability, and a mobile user can master the migration state of the task in real time in the task migration process.

Description

Technical Field

[0001] The present invention belongs to the technical field of mobile edge computing, and in particular relates to a composite three-way handshake migration method for edge computing. Background Art

[0002] Mobile Edge Computing (MEC) deploys servers near the radio access network (RAN) to provide services and cloud computing capabilities required by user equipment (UE, hereinafter referred to as users), with the advantages of high performance, low latency and high bandwidth. The MEC server includes the MEC platform and multiple applications deployed on the MEC platform. When the UE is connected to the MEC server, it can offload tasks to the MEC server for execution and obtain application data from the MEC server.

[0003] Due to the mobility of UE or the connected MEC server is too busy, the task offloaded to the source MEC server needs to be migrated to the target MEC server. There are three problems in the process of task migration: ① The three subjects use three-way handshakes respectively, which is time-consuming and energy-consuming, and two independent connections need to be managed, resulting in duplication of connection resources on the subject; ② The migration of tasks will affect the continuity of services, and it is necessary to design a simple migration process on the basis of maintaining reliability to reduce the interruption time of services; ③ The migration of tasks will affect the continuity of services, so it is necessary to process the task status during the task migration period to reduce the impact of service interruption. Based on this, the present invention designs a task migration mechanism.

[0004] Through the above analysis, the problems and defects of the existing technology are as follows: for the source server, mobile user, and target server, the source server needs to establish two separate connections with the mobile user and the target server respectively, and control and manage the message sequence number and retransmission respectively, resulting in a large number of control messages and cumbersome procedures; and during the task migration process, the mobile user cannot grasp the migration status of the task in real time. Summary of the invention

[0005] In order to overcome the problems existing in the related art, the embodiment disclosed in the present invention provides a composite three-way handshake migration method for edge computing, and the technical solution is as follows:

[0006] The present invention is implemented as follows: a composite three-way handshake migration method for edge computing, wherein the source server implements task migration according to the task migration notification; the migration process is divided into three stages, namely, the composite three-way handshake stage for establishing a connection, the data transmission stage, and the composite three-way handshake stage for releasing the connection;

[0007] When establishing a communication connection, three entities are introduced, namely the source server, the target server and the mobile user. The source server establishes a communication connection with the target server, and the source server sends a notification of establishing a communication connection to the target server and the mobile user through a composite three-way handshake. The mobile user determines that the task is about to enter the migration state.

[0008] The mobile user stops transmitting the migration task data to the source server; the source server divides the task and generates a task information table, sends the task identification number and the task information table, and sends a response message of receiving the task information table; after completing the exception handling, the target server sends the migration task identification number and task data to complete the task migration;

[0009] The source server sends a connection release message to the target server and the mobile user by waving three times in combination; the target server and the vehicle among the mobile users receive the connection release message and send a confirmation message; after the source server receives the connection release message from the target server, it sends a confirmation message; after the source server receives the connection release message from the vehicle, it sends a confirmation message.

[0010] Furthermore, the applications in the source server are application services, including application software that provide computing, access and routing functions. The migration application provides proxy services for the task migration mechanism. Mobile users are users of the services and move from the source server to the target server. The target server provides the same functions as the source server and continues to provide the same application services as the source server to mobile users after executing seamless task migration.

[0011] Furthermore, the initial communication state between the source server and the target server is in the CLOSED state. The source server actively opens the connection, and the target server passively opens the connection. The connection establishment phase specifically includes:

[0012] Step 101: The migration application of the source server senses through external information that the mobile user is about to leave the service range, and sends a task identification number to the application to identify this migration service;

[0013] Step 102: the task data originally provided to the mobile user by the application is sent to the migration application;

[0014] Step 103: The source server sends a connection request message to the target server, the SYN bit in the message header is 1, and the initial sequence number seq is selected as x;

[0015] Step 104: After receiving the request message, if the target server agrees to connect, it sends a confirmation message; in the confirmation message, ACK=1, SYN=1, the confirmation number is ack=x+1, and the sequence number seq=y is initialized at the same time;

[0016] Step 105: The source server sends a message to the vehicle to establish a connection with the target MEC, and sends a confirmation message with ACK=1, ack=y+1, and sequence number seq=x+1;

[0017] Step 106: After receiving the confirmation, the source server gives confirmation to the target server; the confirmation message has ACK=1, ack=y+1, and sequence number seq=x+1; at this time, the source server and the target server enter the ESTABLISHED state where the connection has been established.

[0018] In step 102, the task data originally provided to the mobile user by the application includes services, calculations and results.

[0019] Furthermore, the data transmission phase includes:

[0020] Step 201: The vehicle stops transmitting data of the migration task to the source server;

[0021] Step 202: The migration application of the source server divides the received tasks and generates a task information table, which is divided into executing tasks and unexecuted tasks; the target server completes the transmission and merges the tasks according to the received task information table, and notifies the mobile user in step 211;

[0022] Step 203: The source server migration application sends the task identification number and task information table to be migrated to the target server migration application in a TCP data packet seq=x+2,...n;

[0023] Step 204: the target server migration application sends a TCP data packet ACK=1, seq=x+n to the source server migration application to confirm receipt;

[0024] Step 205: The source server migrates the application to the target server, and transmits the task with TCP data packet seq=x+n+…;

[0025] Step 206: When the target server migration application finds that the task packet is lost, it sends a retransmission request to the source server migration application;

[0026] Step 207: The source server retransmits the lost packet to the target server;

[0027] Step 208: The migration application of the target server sends the migration task identification number and task data to the application;

[0028] Step 209: The target server application parses the data, confirms that the task information table messages are received and the CRC check code is correct, and sends a task confirmation message to the migration application; if there is an error, a retransmission request is sent according to the TCP message sequence number;

[0029] Step 210: the target server migration application sends a notification of receiving completion to the original server migration application;

[0030] Step 211: The target server migration application sends a task migration completion notification to the vehicle.

[0031] In step 202, the migration application of the target server is completed after the overall procedure;

[0032] After the calculation of the executing tasks is completed, they are transmitted to the migration application of the target server in the data transmission phase; the unexecuted tasks are also transmitted to the migration application of the target server in sequence in the data transmission phase.

[0033] In step 203, the task unique identification number in the task information table is the unique identification number of this task; the task number is the corresponding serial number after the task is divided; the status is the status of this task on the source server, 0 means executing, and 1 means not executed; among them, executing means no migration, and the result must be transmitted to the target server after the source server completes the calculation, and not executed means migration.

[0034] In step 206, the specific packet loss judgment criteria are as follows: the task is sent in sequence according to the TCP message sequence number. When the target server receives two consecutive TCP data packets, but the previous TCP data packet seq=x+n+m-2 is not received, packet loss is judged and the TCP data packet seq=x+n+m-2 is required to be retransmitted.

[0035] Furthermore, the connection release phase includes:

[0036] Step 301: The source server sends a connection release message to the target server and stops sending data;

[0037] Step 302: The source server sends a connection release message to the vehicle;

[0038] Step 303: The target server receives the connection release message and sends a confirmation message;

[0039] Step 304: The vehicle receives the connection release message and sends a confirmation message;

[0040] Step 305: After receiving the connection release message from the target server, the source server sends a confirmation message;

[0041] Step 306: After receiving the connection release message from the vehicle, the source server sends a confirmation message, and the source server and the target server enter the CLOSED state.

[0042] Furthermore, if the task of the mobile user needs to continuously interact with the MEC server to maintain the normal operation of the task, then under the premise that the delay is allowed, after the source MEC and the target MEC establish a connection in step 105, the task data is cached in the mobile user device, and after the migration completion notification sent by the target MEC is received in step 210, the cached task data is uploaded to the target MEC, and then the target MEC provides services to the mobile user.

[0043] Combined with all the above technical solutions, the advantages and positive effects of the present invention are as follows: the present invention reduces the number of connections, reduces the number of control messages, and allows mobile users to clearly know the status. For the source server, mobile user, and target server, the source server originally needs to establish two separate connections with the mobile user and the target server respectively, and control and manage the message sequence number and retransmission respectively. The present invention improves this process, reduces the number of connections to a three-party shared connection, and can reduce the number of control messages in the connection establishment phase and the connection release phase, and at the same time allows the mobile user to clearly know the status of each state, which is conducive to seamless migration of computing tasks on mobile users. The process of the present invention is simple and simplifies the management of connections while maintaining reliability. The composite three-party information interaction established by the invention allows mobile users to grasp the migration status of tasks in real time during the task migration process. In the form of a composite three-way handshake, the number of connections is reduced, the number of control messages is reduced, and the mobile user is clearly aware of the status. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings herein are incorporated in and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the description, serve to explain the principles of the present disclosure;

[0045] Figure 1 It is a flow chart of a composite three-way handshake migration method for edge computing provided by an embodiment of the present invention;

[0046] Figure 2 It is a schematic diagram of the principle of a source server sending a connection request message to a target server provided by an embodiment of the present invention;

[0047] Figure 3 It is a schematic diagram of the principle of migrating tasks being executed or not executed on the source server to the target server when a vehicle moves from a source server to a target server in a connected vehicle network provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0048] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention, so the present invention is not limited by the specific implementation disclosed below.

[0049] The innovation of the edge computing composite three-way handshake migration method provided by the embodiment of the present invention is:

[0050] 1. Composite three-way handshake (steps 103-106): The three-way handshake is used to establish a communication connection. The traditional three-way handshake is used for two entities, namely the client and the server. Since the user needs to obtain the task status at all times during task migration, the present invention introduces a composite three-way handshake for three entities when establishing a communication connection, namely the source MEC server, the target MEC server and the user. The functional principles of these three entities are described as follows: the application in the source server is a related application service, such as application software that provides computing, access, routing and other capabilities, and the migration application provides related proxy services of this task migration mechanism; the mobile user is the user of these related services, and moves from the source server to the target server; the target server provides the same functions as the source server, and after executing the seamless migration of the task, it continues to provide the same application services as the source server to the mobile user. In this process, the source MEC server establishes a communication connection with the target MEC server, and the source MEC server sends a notification of establishing a communication connection to the user, so that the user knows that the task is about to enter the migration state.

[0051] 2. Compound three-wave handshake (steps 301-306): In TCP, four waves are often used to release the connection. The compound three-wave handshake and the four-wave handshake have the following three main differences: (1) The subjects are different. The commonly used four-wave handshake has two subjects, namely the client and the server, while the compound three-wave handshake has three subjects, namely the source MEC server, the target MEC server, and the user; (2) The subjects of releasing the connection are different: the four-wave handshake is used to release the connection between the client and the server, and the compound three-wave handshake is used to release the connection between the UE and the source MEC server, and the source MEC server and the target MEC server. (3) The process steps are different: The four-wave handshake mechanism is as follows:

[0052] ①The TCP client sends a FIN message to close the data transmission from the client to the server.

[0053] ② The server receives the FIN message and sends back an ACK message, confirming that the sequence number is the received sequence number plus 1. Like SYN, a FIN message will occupy one sequence number.

[0054] ③The server closes the client's connection and sends a FIN to the client.

[0055] ④The client sends back an ACK message to confirm and sets the confirmation number to the received number plus 1.

[0056] Since the server may still have data to transmit when the client requests to disconnect, steps (2) and (3) are required when the server responds to the client. In this scenario, the communication between the source MEC server and the target MEC server is only used for task data transmission. When the source MEC server requests to disconnect, the target MEC server has no need to transmit data to the source MEC server, so steps (2) and (3) can be simplified into one step. The user and the source MEC server release the connection in the same way.

[0057] 3. Data retransmission / data transmission process

[0058] In TCP, when the data from the sender reaches the receiver, the receiving host will return a confirmation message to indicate that the message has been received.

[0059] One of the starting points of the present invention is to simplify the migration process. On the basis of maintaining reliability, the step of "confirming the response message" can be cancelled. The specific reasons are as follows: because the size and status of the transmitted task will not change when the transmission starts, the source MEC sends the task information table to the target MEC before the task starts to be transmitted (step 202), so that the target MEC can grasp the overall information of the task. After the task starts to be transmitted, the target MEC can determine the occurrence of "packet loss" through the set mechanism, and then send a retransmission request to the source MEC. In summary, the step of "confirming the response message" can be cancelled on the basis of maintaining the reliability of task transmission.

[0060] In an embodiment, the application service on a mobile user (such as a vehicle or a mobile phone) offloads its computing tasks to a nearby connected edge computing server (source server) due to insufficient computing power. There are two situations where computing tasks need to be migrated: 1. The connection is interrupted because the user moves toward another server (target server), affecting the computing tasks on the source server; 2. The connected source server is too busy and requires computing power support from a nearby target server. The source server implements the task migration based on the task migration notification. The migration process is divided into three stages: connection establishment, data transmission, and connection release.

[0061] like Figure 1 As shown, the edge computing composite three-way handshake migration method provided by the embodiment of the present invention specifically includes the following steps:

[0062] 1. Connection establishment phase

[0063] At the beginning, the communication status between the source server and the target server is in the CLOSED state. The source server actively opens the connection, and the target server passively opens the connection.

[0064] Step 101: The migration application of the source server senses through external information that the user is about to leave the service range, and sends a task identification number to the application to identify this migration service.

[0065] Step 102: The task data (eg, service, calculation, result, etc.) originally provided by the application to the mobile user is sent to the migration application.

[0066] Step 103: The source server sends a connection request message to the target server, just like a TCP message, with the same bit SYN=1 in the message header, and an initial sequence number seq=x is selected, such as Figure 2 shown.

[0067] The connection request message includes:

[0068] 1. Source Port and Destination Port: They occupy 2 bytes respectively and are used to distinguish different processes in the host. The IP address is used to distinguish different hosts. The source port number and destination port number together with the source IP address and destination IP address in the IP header can uniquely identify a TCP connection.

[0069] 2. Sequence Number (seq): occupies 4 bytes and is used to identify the data byte stream sent from the TCP sender to the TCP receiver (each byte transmitted by TCP is numbered in sequence). It indicates the sequence number of the first data byte in this message segment in the data stream. It is mainly used to solve the problem of disordered network messages.

[0070] 3. Acknowledgment Number: 4 bytes. The acknowledgment number contains the next number that the end sending the acknowledgment expects to receive. Therefore, the acknowledgment number should be the last successfully received data byte number plus 1. However, the acknowledgment number field is only valid when the ACK flag in the flag bit is 1. It is mainly used to solve the problem of packet loss (the acknowledgment number minus the last received number is equal to the length of the message received in this segment).

[0071] 4. Data offset (Offset): occupies 4 bits, indicating how far the data start of the TCP segment is from the start of the TCP segment. This field actually indicates the header length of the TCP segment. This value is needed because the length of the optional field is variable. It is used to indicate the number of 32-bit (4-byte) words in the header, so it can represent up to 15 32-bit words, that is, 4*15=60 bytes of header length), so TCP has a maximum of 60 bytes of header. However, without the optional field, the normal length is 20 bytes.

[0072] Step 104: After receiving the request message, if the target server agrees to connect, it sends a confirmation message, which should contain ACK=1, SYN=1, and the confirmation number is ack=x+1. It also initializes a sequence number seq=y for itself.

[0073] The criteria for agreeing to connect are: if a complete message is received and verified to be correct, the connection is agreed; if the CRC check code is incorrect, it is considered a message transmission error and the connection is rejected.

[0074] In the TCP protocol, each byte is assigned a unique sequence number. These sequence numbers are assigned by the sender and transmitted to the receiver in the data packet. The main purpose of the sequence number is to ensure the order and integrity of the data packet. The sender uses a 32-bit counter called a "sequence number" to generate the sequence number. Every time the sender sends a data packet, it increases the value of the sequence number. The receiver determines the order of the data packets based on the sequence number of the received data packet and processes the data accordingly.

[0075] Step 105: The source server sends a message to the vehicle to establish a connection with the target MEC, that is, ACK=1 of the confirmation message, ack=y+1, and its own sequence number seq=x+1.

[0076] Step 106: After receiving the confirmation, the source server also sends a confirmation to the target server. The confirmation message has ACK=1, ack=y+1, and its own sequence number seq=x+1. At this point, the source server and the target server enter the ESTABLISHED (connection established) state.

[0077] 2. Data transmission stage

[0078] Step 201: The vehicle stops transmitting data of the migration task to the source server.

[0079] Step 202: The migration application of the source server divides the received tasks and generates a task information table, which is mainly divided into tasks in execution (non-migratable) and unexecuted (migratable). After the execution tasks are calculated, they are transmitted to the migration application of the target server in the data transmission stage; the unexecuted tasks are also transmitted to the migration application of the target server in sequence in the data transmission stage. After the migration application of the target server completes the overall process. The target server merges the transmission of the task migration according to the received task information table, and notifies the mobile user in step 211.

[0080] Step 203: The source server migration application sends the task identification number and task information table to be migrated to the target server migration application in a TCP data packet (seq=x+2,...n). The task information is shown in Table 1. The task unique identification number is the unique identification number (ID) of this task, such as KA001; the task number is the corresponding sequence number after the task is divided; the status is the status of this task in the source server, 0 means being executed (cannot be migrated, need to wait for the source server to complete the calculation and transmit the result to the target server), 1 means not being executed (can be migrated).

[0081] Table 1 Task information

[0082]

[0083]

[0084] Step 204: The target server migration application sends a TCP data packet ((ACK=1, seq=x+n)) to confirm receipt of the information to the source server migration application.

[0085] Step 205: The source server migrates the application to the target server, and transmits the task with a TCP data packet (seq=x+n+...).

[0086] Step 206: When the target server migration application finds that the task packet is lost, it sends a retransmission request to the source server migration application. The specific packet loss judgment criteria are as follows: the tasks are sent in sequence according to the TCP message sequence number. When the target server receives two consecutive TCP data packets, but the previous TCP data packet (seq = x + n + m-2) is not received, it is judged that the packet is lost and requires the TCP data packet (seq = x + n + m-2) to be retransmitted.

[0087] Step 207: The source server retransmits the lost packet to the target server.

[0088] Step 208: The migration application of the target server sends the migration task identification number and task data to the application.

[0089] Step 209: The application of the target server parses the data, confirms that all task information table messages are received and the CRC check code is correct, and sends a task confirmation message to the migration application; if there is an error, a retransmission request is sent according to the TCP message sequence number.

[0090] Step 210: The target server migration application sends a notification of receiving completion to the original server migration application.

[0091] Step 211: The target server migration application sends a task migration completion notification to the vehicle.

[0092] 3. Connection release phase

[0093] Step 301: The source server sends a connection release message to the target server, sets FIN=1, and stops sending data.

[0094] Step 302: The source server sends a connection release message to the vehicle.

[0095] Step 303: The target server receives the connection release message and sends a confirmation message, setting FIN=1, ACK=1, seq=w, ack=u+1.

[0096] Step 304: The vehicle receives the connection release message and sends a confirmation message.

[0097] Step 305: After receiving the connection release message from the target server, the source server needs to send a confirmation message, setting ACK=1, seq=u+1, ack=w+1.

[0098] Step 306: After receiving the connection release message from the vehicle, the source server needs to send a confirmation message.

[0099] After completing the above steps, the source server and the target server enter the CLOSED state.

[0100] If the user's task needs to continuously interact with the MEC server to maintain the normal operation of the task, the continuity of the service will inevitably be affected during the task migration process. In the face of this problem, if the delay is allowed, after receiving the connection between the source MEC and the target MEC in step 105, the task data is cached in the user device, and after receiving the migration completion notification sent by the target MEC in step 210, the cached task data is uploaded to the target MEC, and then the target MEC provides services to the user.

[0101] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0102] In the Internet of Vehicles, MEC servers provide services to vehicles through edge computing technology, such as computing services, application services, access services, etc. Due to the mobility of vehicles, when the vehicle moves from the source server (MECS) to the target server (MECT), the tasks being executed or not executed on the source server need to be migrated to the target server, such as Figure 3 shown.

[0103] The source server transmits data to the mobile server in real time, and determines that the user is moving to the target server through environmental perception (e.g. SINR: Signal to Interference plus Noise Ratio), so it starts step 101 in the migration application, notifies the application to start service migration, and transfers the task data (e.g. service, calculation, result, etc.) originally provided to the mobile user to the migration application through step 102. Then, the migration application of the source server sends a connection request message to the target server through step 103, sets the same bit SYN=1 in the message header, and selects an initial sequence number seq=x. After receiving the request message, if the target server agrees to connect, it sends a confirmation message, sets ACK=1, SYN=1 in the message, and the confirmation number is ack=x+1, and also initializes a sequence number seq=y for itself. Then, the source server sends a message to the vehicle to establish a connection with the target MEC through step 105, that is, ACK=1, ack=y+1, and its own sequence number seq=x+1 in the confirmation message, and responds to the target server to give a connection confirmation in step 106, setting its confirmation message ACK=1, ack=y+1, and its own sequence number seq=x+1. At this point, the source server and the target server have completed the ESTABLISHED (established connection) state.

[0104] After receiving step 105, i.e., in step 201, the mobile user stops transmitting the data of the migration task to the source server; and after entering the data transmission phase, the source server executes step 202 to divide the received task and generate a task information table. The target server completes the transmission of the task migration according to the received task information table and notifies the mobile user in step 211. Then, in step 203, the source server sends the task identification number and task information table to be migrated to the target server migration application in a TCP data packet (seq=x+2,...n); in step 204, the target server sends a TCP data packet ((ACK=1, seq=x+n)) to the source server migration application to confirm receipt. In step 205, data transmission continues. When the target server migration application finds that the task packet is lost, a retransmission request is sent to the migration application of the source server in step 206. After receiving the retransmission request, the source server retransmits the lost packet to the target server in step 207. After all task data are transmitted, the migration application of the target server sends the migration task identification number and task data to the application through step 208, and receives the task confirmation message in step 209. Finally, the migration of the target server should send a notification of reception completion to the migration application of the source server and the mobile user in steps 210 and 211 respectively.

[0105] Entering the connection release phase, the source server sends a connection release message to the target server and the mobile user in steps 301 and 302 respectively, and stops sending data. The target server and the mobile user respond to the connection release message in steps 303 and 304 respectively, and send a confirmation message. Finally, the source server sends a confirmation message to the target server and the mobile user in steps 305 and 306 respectively to release the connection, completing the task migration and ending the communication connection.

[0106] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any modifications, equivalent substitutions and improvements made by any technician familiar with the technical field within the technical scope disclosed by the present invention and within the spirit and principles of the present invention should be covered within the protection scope of the present invention.

Claims

1. A composite three-way handshake migration method for edge computing, characterized in that: The method comprises: the source server implements task migration according to the task migration notification; the migration process is divided into three stages, namely, a composite three-way handshake stage for establishing a connection, a data transmission stage, and a composite three-way handshake stage for releasing a connection; When establishing a communication connection, three entities are introduced, namely the source server, the target server and the mobile user. The source server establishes a communication connection with the target server, and the source server sends a notification of establishing a communication connection to the target server and the mobile user through a composite three-way handshake. The mobile user determines that the task is about to enter the migration state. The mobile user stops transmitting the migration task data to the source server; the source server divides the task and generates a task information table, sends the task identification number and the task information table, and sends a response message of receiving the task information table; after completing the exception handling, the target server sends the migration task identification number and task data to complete the task migration; The source server sends a connection release message to the target server and the mobile user by waving three times in combination; the target server and the vehicle among the mobile users receive the connection release message and send a confirmation message; after the source server receives the connection release message from the target server, it sends a confirmation message; after the source server receives the connection release message from the vehicle, it sends a confirmation message.

2. The composite three-way handshake migration method for edge computing according to claim 1, characterized in that: The applications in the source server are application services, including application software that provide computing, access and routing functions. The migration application provides proxy services for the migration mechanism of this task. Mobile users are users of the services and move from the source server to the target server. The target server provides the same functions as the source server and continues to provide the same application services as the source server to mobile users after executing seamless task migration.

3. The composite three-way handshake migration method for edge computing according to claim 2, characterized in that: The initial communication state between the source server and the target server is in the CLOSED state. The source server actively opens the connection, and the target server passively opens the connection. The connection establishment phase specifically includes: Step 101: The migration application of the source server senses through external information that the mobile user is about to leave the service range, and sends a task identification number to the application to identify this migration service; Step 102: the task data originally provided to the mobile user by the application is sent to the migration application; Step 103: The source server sends a connection request message to the target server, the SYN bit in the message header is 1, and the initial sequence number seq is selected as x; Step 104: After receiving the request message, if the target server agrees to connect, it sends a confirmation message; in the confirmation message, ACK=1, SYN=1, the confirmation number is ack=x+1, and the sequence number seq=y is initialized at the same time; Step 105: The source server sends a message to the vehicle to establish a connection with the target MEC, and sends a confirmation message with ACK=1, ack=y+1, and sequence number seq=x+1; Step 106: After receiving the confirmation, the source server gives confirmation to the target server; the confirmation message has ACK=1, ack=y+1, and sequence number seq=x+1; at this time, the source server and the target server enter the ESTABLISHED state where the connection has been established.

4. The composite three-way handshake migration method for edge computing according to claim 3, characterized in that: In step 102, the task data originally provided to the mobile user by the application includes services, calculations and results.

5. The composite three-way handshake migration method for edge computing according to claim 1, characterized in that: The data transmission phase includes: Step 201: The vehicle stops transmitting data of the migration task to the source server; Step 202: The migration application of the source server divides the received tasks and generates a task information table, which is divided into executing tasks and unexecuted tasks; the target server completes the transmission and merges the tasks according to the received task information table, and notifies the mobile user in step 211; Step 203: The source server migration application sends the task identification number and task information table to be migrated to the target server migration application in a TCP data packet seq=x+2,...n; Step 204: the target server migration application sends a TCP data packet ACK=1, seq=x+n to the source server migration application to confirm receipt; Step 205: The source server migrates the application to the target server, and transmits the task with TCP data packet seq=x+n+…; Step 206: When the target server migration application finds that the task packet is lost, it sends a retransmission request to the source server migration application; Step 207: The source server retransmits the lost packet to the target server; Step 208: The migration application of the target server sends the migration task identification number and task data to the application; Step 209: The target server application parses the data, confirms that the task information table messages are received and the CRC check code is correct, and sends a task confirmation message to the migration application; if there is an error, a retransmission request is sent according to the TCP message sequence number; Step 210: the target server migration application sends a notification of receiving completion to the original server migration application; Step 211: The target server migration application sends a task migration completion notification to the vehicle.

6. The composite three-way handshake migration method for edge computing according to claim 5, characterized in that: In step 202, the migration application of the target server is completed after the overall procedure; After the calculation of the executing tasks is completed, they are transmitted to the migration application of the target server in the data transmission phase; the unexecuted tasks are also transmitted to the migration application of the target server in sequence in the data transmission phase.

7. The composite three-way handshake migration method for edge computing according to claim 5, characterized in that: In step 203, the task unique identification number in the task information table is the unique identification number of this task; the task number is the corresponding serial number after the task is divided; the status is the status of this task on the source server, 0 means executing, and 1 means not executed; among them, executing means no migration, and the result must be transmitted to the target server after the source server completes the calculation, and not executed means migration.

8. The composite three-way handshake migration method for edge computing according to claim 5, characterized in that: In step 206, the specific packet loss judgment criteria are as follows: the task is sent in sequence according to the TCP message sequence number. When the target server receives two consecutive TCP data packets, but the previous TCP data packet seq=x+n+m-2 is not received, packet loss is judged and the TCP data packet seq=x+n+m-2 is required to be retransmitted.

9. The composite three-way handshake migration method for edge computing according to claim 1, characterized in that: The connection release phase includes: Step 301: The source server sends a connection release message to the target server and stops sending data; Step 302: The source server sends a connection release message to the vehicle; Step 303: The target server receives the connection release message and sends a confirmation message; Step 304: The vehicle receives the connection release message and sends a confirmation message; Step 305: After receiving the connection release message from the target server, the source server sends a confirmation message; Step 306: After receiving the connection release message from the vehicle, the source server sends a confirmation message, and the source server and the target server enter the CLOSED state.

10. The composite three-way handshake migration method for edge computing according to claim 1, characterized in that: If the task of the mobile user needs to continuously interact with the MEC server to maintain the normal operation of the task, then under the premise that the delay is allowed, after the source MEC and the target MEC establish a connection in step 105, the task data is cached in the mobile user device, and after the migration completion notification sent by the target MEC is received in step 210, the cached task data is uploaded to the target MEC, and then the target MEC provides services to the mobile user.

Images