SDN-based edge computing node task resource scheduling method and system, and medium

Abstract

The application provides an SDN-based edge computing node task resource scheduling method and system and a medium. The method comprises the following steps: receiving a current access point identifier and a service flow first packet of a user equipment, extracting a flow identity marker to form a flow traceability identifier pair; querying an access point-edge service mapping view to generate a service location candidate set containing a current service and adjacent alternative locations; creating a primary flow table item for a primary edge computing node at a first switch, and simultaneously pre-building shadow flow table items in a low-priority dormant state for all adjacent nodes; synchronizing the service context of the flow service to all adjacent nodes and placing them in an activated state; when the user equipment switches to an adjacent access point, a second switch connected to the new access point automatically matches and wakes up the corresponding shadow flow table item according to the flow identity marker, instantly raises the priority of the shadow flow table item to cover the primary flow table item, and triggers a service context activation signal, thereby realizing uninterrupted takeover of the service flow.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to a method, system, and medium for scheduling task resources of edge computing nodes based on SDN. Background Technology

[0002] In edge computing environments, service flows initiated by user devices during movement need to be processed by computing nodes at the network edge. When a user device moves from the coverage area of ​​one access point to the coverage area of ​​another, the corresponding service instance needs to be migrated from the current edge computing node to the target edge computing node to maintain service continuity. In existing technologies, the SDN controller typically continuously collects the signal strength of user devices and predicts their movement trajectory accordingly. When a handover is anticipated, the service instance is started in advance at the predicted target node, and flow tables are issued, with traffic redirection performed after the handover is complete. However, this prediction-based scheduling method has inherent uncertainties due to the time-varying characteristics of the signal propagation environment. The deviation between the prediction result and the user's actual movement direction will cause service instances to be ineffectively started at incorrect nodes, wasting computing resources and requiring a complete service reconstruction and flow table reconfiguration process to be executed when the actual handover occurs, introducing additional service interruption time. Summary of the Invention

[0003] This invention provides a method, system, and medium for scheduling task resources of edge computing nodes based on SDN.

[0004] In a first aspect, embodiments of the present invention provide a method for scheduling task resources of an edge computing node based on SDN, including: The system receives the current access point identifier of the user equipment and the first packet of the user equipment's service flow synchronized by the SDN controller, extracts the flow identity tag from the first packet of the service flow, and uses the current access point identifier and the flow identity tag as a flow tracing identifier pair. Based on the flow tracing identifier, query the pre-built access point-edge service mapping view, obtain the current service edge computing node identifier bound to the current access point identifier and the set of adjacent edge computing node identifiers bound to all adjacent access point identifiers that have an adjacency relationship with the current access point identifier, and generate a service location candidate set containing the current service location and alternative service locations; Send a flow table shadow construction instruction carrying flow identity tags and service location candidate sets to the SDN controller, so that the SDN controller creates a primary flow table entry pointing to the current service edge computing node identifier for the flow identity tag at the first switch connected to the current access point, and creates a corresponding shadow flow table entry for each adjacent edge computing node identifier in the service location candidate set. Each shadow flow table entry has a lower priority than the primary flow table entry and is initially in a dormant state. After the first switch completes the installation of all shadow flow table entries, it sends a service status synchronization instruction carrying a flow identity tag to all edge computing nodes in the service location candidate set. The service status synchronization instruction instructs each edge computing node to synchronize the service context associated with the flow identity tag from the current service edge computing node according to the flow identity tag, and set the synchronized service context to the pending activation state. When a user device switches from the current access point to any adjacent access point, the second switch connected to the new access point automatically matches and wakes up a corresponding dormant shadow flow table entry based on the flow identity tag. The priority of the woken shadow flow table entry is instantly increased and it overrides the primary flow table entry. At the same time, a service context activation signal pointing to the corresponding adjacent edge computing node is triggered, completing the uninterrupted takeover of the service flow.

[0005] Secondly, embodiments of the present invention provide a computer system including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement the steps in the above method.

[0006] Thirdly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method.

[0007] This invention generates a candidate set of service locations by receiving flow origination identifiers and querying the access point-edge service mapping view. It then sends a flow table shadow construction command to the SDN controller to pre-create a primary flow table entry pointing to the current service node and dormant shadow flow table entries pointing to each adjacent edge node in the access switch. Simultaneously, it synchronizes the service context to all candidate edge nodes and sets them to an active state. When a user equipment experiences an access point switchover, the new access switch automatically matches and wakes up the corresponding shadow flow table entry based on the flow identity tag, instantly prioritizing it to cover the primary flow table entry and triggering a service context activation signal to complete uninterrupted takeover. This method decentralizes the critical actions of service migration from the control plane to the data plane, allowing path switching to be autonomously completed by the switch hardware during packet forwarding. This eliminates latency jitter caused by control plane signaling interaction and ensures the continuity of service flows. Furthermore, by pre-distributing the service context to candidate nodes with topological adjacency, only activation is required during switching, avoiding redundant pre-starting and resource waste due to inaccurate mobility prediction, and achieving deterministic and immediate response to user mobility. Attached Figure Description

[0008] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present invention and, together with the specification, serve to explain the technical solutions of the present invention.

[0009] Figure 1This is a schematic diagram illustrating the principle of an edge computing node task resource scheduling method based on SDN, provided in an embodiment of the present invention.

[0010] Figure 2 This is a schematic diagram illustrating the implementation process of an edge computing node task resource scheduling method based on SDN, provided in an embodiment of the present invention.

[0011] Figure 3 This is a schematic diagram of the hardware entity of a computer system provided in an embodiment of the present invention. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on the present invention. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] This invention provides a method for scheduling task resources on an edge computing node based on SDN, which can be executed by a processor of a computer system. The computer system can refer to an edge computing orchestrator server or an application server.

[0014] Please unite Figure 1 and Figure 2 Referring to the present invention, an edge computing node task resource scheduling method based on SDN is provided, which includes the following steps: Step S100: Receive the current access point identifier and the first packet of the service flow of the user equipment synchronized by the SDN controller, extract the flow identity tag from the first packet of the service flow, and use the current access point identifier and the flow identity tag as a flow tracing identifier pair.

[0015] Software-defined networking (SDN) is a new network architecture that separates the control plane from the data forwarding plane of network devices, and dynamically manages and optimizes the network through a centralized controller using software programming. The SDN controller is the core control entity in this architecture, responsible for maintaining the global network topology view, managing network resources, and issuing flow table rules to lower-level switches. It communicates with data plane devices via a southbound interface protocol. User equipment (UE) is the terminal entity that initiates service requests, such as smartphones, laptops, or IoT terminals, which access the network via wireless signals. The Current Access Point Identifier (CPI) is a unique identifier of the wireless access point actually associated with the UE when initiating a service request. This identifier is pre-assigned during the network planning phase, for example, using a Media Access Control (MAC) address or a custom string identifier defined by the network administrator. The first packet of a service flow is the first data packet generated when a UE initiates a new service connection. This packet typically carries information identifying the characteristics of the entire service flow. A flow identity tag is a combination of characteristic fields extracted from the first packet of a service flow that uniquely identifies the flow. This could be a 5-tuple consisting of the source Internet Protocol address, destination Internet Protocol address, source port number, destination port number, and protocol type, or a fixed-length digest value obtained by hashing the aforementioned 5-tuple. A flow origination tag is a binary data structure composed of the current access point identifier and the flow identity tag, used to uniquely trace the origin and identity information of a service flow across the entire network.

[0016] Step S200: Based on the flow tracing identifier, query the pre-built access point-edge service mapping view, obtain the current service edge computing node identifier bound to the current access point identifier and the set of adjacent edge computing node identifiers bound to all adjacent access point identifiers that have an adjacency relationship with the current access point identifier, and generate a service location candidate set containing the current service location and alternative service locations.

[0017] In one implementation, step S200 may specifically include the following steps S210 to S260: Step S210: Parse the flow tracing identifier pair, separate the current access point identifier and the flow identity tag, use the current access point identifier as the index key value, and query the locally cached access point-edge service mapping view from the SDN controller. The access point-edge service mapping view is organized with the access point identifier as the primary key and the associated set of edge computing node identifiers as the key value.

[0018] In this embodiment, the flow scheduling management process inside the SDN controller retrieves the flow origination identifier pair data structure from the global flow state table. This data structure is stored in memory as a contiguous block of bytes, where the first few bytes are the length and content of the current access point identifier, and the subsequent bytes are the hash value of the flow identity tag. The parsing process first reads the length field at a fixed offset in the header of the data structure to obtain the byte length of the current access point identifier, and then copies the binary content of the current access point identifier to an independent string variable based on this length. Next, starting from the position after the length field of the data structure, a fixed-length byte sequence is read as the flow identity tag. After parsing is completed, the flow scheduling management process uses the string of the current access point identifier as the index key to call the local mapping view query interface of the SDN controller. This interface internally maintains an index structure based on a balanced binary search tree or hash table, which can locate the corresponding key-value storage location through the access point identifier primary key in constant or logarithmic time complexity, thereby obtaining the set of edge computing node identifiers associated with the access point identifier.

[0019] Step S220: Read the edge computing node identifier directly associated with the current access point identifier from the access point-edge service mapping view, determine the edge computing node identifier as the current service edge computing node identifier, and obtain the service status description corresponding to the current service edge computing node identifier. The service status description includes the current load status and a list of running service instances.

[0020] The service status description is a real-time snapshot data structure maintained by the SDN controller for each registered edge computing node. This data structure is proactively reported by the edge computing node periodically via heartbeat messages, or collected and updated by the SDN controller's monitoring process through proactive polling. The current load status is a multi-dimensional resource utilization metric vector, including current values ​​for metrics such as CPU utilization, memory utilization, network I / O bandwidth utilization, and hardware accelerator utilization. These values ​​are typically expressed as percentages or absolute amounts. The list of running service instances is a list structure that records the unique identifiers of all service instances currently running on the edge computing node and their corresponding flow identity tags. Each service instance corresponds to a business flow context that is being processed.

[0021] During the query process, after the SDN controller's flow scheduling management process locates the key-value entry corresponding to the current access point identifier in the access point-edge service mapping view through the index key-value in step S210, it first reads the edge computing node identifier field stored in the entry. This field may store a single node identifier or a list of node identifiers. If it is a list of node identifiers, the most suitable node identifier is selected from the list as the current service edge computing node identifier according to the pre-configured load balancing strategy, such as weighted round-robin or least connections first algorithm. After determining the current service edge computing node identifier, the flow scheduling management process immediately initiates a query on the edge computing node status table, using the node identifier as an index to obtain the latest reported service status description binary block of the node. This binary block is encoded according to a fixed protocol format, where the first few bytes are the current load status field, containing multiple consecutive floating-point numbers or integers, corresponding to the utilization rate of each resource dimension in turn; the following bytes are the running service instance list field, which first uses an integer to represent the number of service instances in the list, followed by the unique identifier and associated flow identity tag of each service instance in sequence.

[0022] Step S230: Query the topology adjacency extension table of the access point-edge service mapping view. The topology adjacency extension table defines the adjacency association between each access point identifier and other access point identifiers with physical signal coverage overlap. Based on the adjacency association, retrieve all adjacent access point identifiers that have an adjacency relationship with the current access point identifier from the topology adjacency extension table.

[0023] In one implementation, step S230 may specifically include the following steps S231 to S236: Step S231: Extract the embedded topology adjacency extension table from the access point-edge service mapping view. The topology adjacency extension table is stored in the form of an adjacency matrix with the access point identifier as the row index and the list of adjacent access point identifiers as the row data.

[0024] Adjacency matrix storage is a data storage method that uses a two-dimensional matrix structure to represent the adjacency relationships between nodes. The rows and columns of the matrix correspond to the identifiers of all access points in the network. The element in the i-th row and j-th column is a binary identifier or weight value, indicating whether there is an adjacency association between the access point identifiers in the row and column, and the strength of that association. In actual storage implementation, to save storage space, this matrix is ​​stored using a sparse row compression format, that is, only a list of column indices with non-zero elements is maintained for each row. Specifically, the flow scheduling management process calls the application programming interface (API) of the access point-edge service mapping view, passing in a predefined view partition identifier. This identifier points to a specific memory partition within the view used to store the topology adjacency extension table. The API first performs access permission verification on the caller. If the verification passes, it returns the base address and partition size descriptor of the memory partition. The flow scheduling management process allocates a memory buffer of the same size locally according to the partition size descriptor, and then uses a memory block copy function to copy the entire binary content of the topology adjacency extension table from the shared memory area of ​​the SDN controller to this buffer, thus completing the retrieval operation.

[0025] Step S232: Based on the current access point identifier, perform a binary search in the row index of the topology adjacency extension table to locate the row record that completely matches the current access point identifier. If no matching row record is found, return an empty set of adjacency access point identifiers and end the query process.

[0026] The row index of the topology adjacency expansion table is an ordered array structure that stores the lexicographical order of all access point identifiers. Each array element contains an access point identifier string and an offset pointer to the corresponding row data storage location in the adjacency matrix. The binary search process is executed by the flow scheduling management process calling the standard binary search library function. This function uses the string of the current access point identifier as the search target and the starting address of the row index array and the total number of elements as the search range. When the function executes, it first calculates the index of the middle position of the search range, reads the access point identifier at that position and compares it with the target identifier. If they are equal, it returns the row record pointer at that position; if the target identifier is lexicographically smaller than the middle identifier, it shrinks the search range to the first half, and vice versa, recursively executing until a matching record is found or the search range is empty. If no matching record is found after traversing the entire search range, it means that the current access point identifier was not entered into the topology adjacency expansion table during the network planning phase and belongs to an isolated access point. In this case, the function returns a null pointer. When the flow scheduling management process detects a null pointer, it creates an empty list with an initial capacity of zero as the set of adjacent access point identifiers, directly terminates the current topology adjacency query process, and records a diagnostic event of an empty adjacency query result in the log.

[0027] Step S233: Read the stored list of adjacency access point identifiers from the located row record, use the list of adjacency access point identifiers as the initial adjacency set, and at the same time create a temporary set to store the extended adjacency results.

[0028] After the binary search successfully locates the row record corresponding to the current access point identifier, the flow scheduling management process accesses the data storage area of ​​the adjacency matrix based on the offset pointer stored in the row index. The data storage format for this row is as follows: an integer adjacency access point count, indicating the total number of adjacency access points in the row; followed by several fixed-length or variable-length encoded access point identifier strings, each string corresponding to a direct adjacency access point identifier. The flow scheduling management process first reads the adjacency access point count, then iteratively reads that number of access point identifier strings, adding them one by one to an initial adjacency set data structure. The initial adjacency set is implemented as an unordered set based on a hash table, supporting element insertion and member lookup operations with constant time complexity. Simultaneously, the flow scheduling management process allocates a temporary set data structure in the memory heap area, also implemented based on a hash table. This temporary set is initially empty and is used to store newly added adjacency access point identifiers discovered during subsequent extended searches.

[0029] Step S234: For each adjacent access point identifier in the initial adjacency set, check whether it has been marked as processed. If it has not been marked, add the adjacent access point identifier to the temporary set and mark it as processed. At the same time, check whether the row record of the adjacent access point identifier contains the adjacent adjacent access point identifier.

[0030] To track processing progress, the flow scheduling management process maintains a processed marker bitmap in memory. This bitmap uses the hash value of the access point identifier as an index, with each bit corresponding to the processing status of an access point identifier. A bit value of 1 indicates that it has been processed, and a bit value of 0 indicates that it has not been processed. The flow scheduling management process iteratively processes each adjacent access point identifier in the initial adjacency set. For the adjacent access point identifier in the current iteration, its hash value is first calculated, and the corresponding bit in the bitmap is located based on the hash value. The value of that bit is read using a bit test instruction. If the bit is 1, it means that the adjacent access point identifier has been processed in the previous expansion process, so the identifier is skipped and the process proceeds directly to the next iteration. If the bit is 0, it means that the identifier has not been processed yet. The flow scheduling management process performs three operations: First, insert the adjacent access point identifier into a temporary set; Second, set the corresponding bit in the bitmap to 1 using a bit setting instruction to complete the marking; Third, use the adjacent access point identifier as a new index key value to re-execute the query operations in steps S232 and S233 to obtain the list of secondary adjacent access point identifiers directly associated with the adjacent access point identifier from the topology adjacency extension table, i.e., the adjacent adjacent access point identifiers, for use in subsequent steps.

[0031] Step S235: If the row record of the currently processed adjacent access point identifier contains adjacent adjacent access point identifiers, then compare these adjacent adjacent access point identifiers with the initial adjacent set, append new identifiers that do not belong to the initial adjacent set to the temporary set, and repeat this expansion step until no new identifiers are appended.

[0032] After obtaining the list of neighboring access point identifiers associated with the currently processed neighboring access point identifier, the flow scheduling management process compares the membership of each identifier in this list with the initial neighbor set. The comparison operation utilizes the hash table member lookup function of the initial neighbor set, calculating the hash value of the identifier to be compared and checking if the identifier already exists in the hash table. If the identifier to be compared already exists in the initial neighbor set, it means that the identifier is either an initially known neighboring access point or an identifier that was discovered and added to the initial neighbor set in a previous iteration; in this case, the identifier is ignored and not processed. If the identifier to be compared is not in the initial neighbor set, it means that the identifier is a newly discovered indirect neighboring access point during this expansion process. The new identifier is then appended to both the temporary set and the initial neighbor set. Appending it to the initial neighbor set ensures that subsequent iterations can continue to perform depth expansion based on this new identifier, while appending it to the temporary set ensures the integrity of the final output. The flow scheduling management process employs a breadth-first search strategy, treating newly added identifiers to the temporary set in each iteration as candidate identifiers for the next round of processing. The entire expansion step is executed within a loop, which terminates when no new identifier is added to the temporary set in a complete traversal, indicating that all adjacency relationships reachable from the current access point identifier have been traversed.

[0033] Step S236: Take all the access point identifiers in the temporary set as the final retrieved all adjacent access point identifiers that are adjacent to the current access point identifier, and write the retrieval result into the query result buffer.

[0034] The query result buffer is a fixed-size circular buffer pre-allocated in memory by the flow scheduling management process, specifically used to store the retrieval results of adjacent access point identifiers. This buffer is protected by a mutex lock to ensure safe concurrent access. After the extended loop in step S235 ends, the temporary set contains all directly and indirectly adjacent access point identifiers. The flow scheduling management process traverses the temporary set, copying each access point identifier in the set sequentially to a contiguous memory location in the query result buffer. During copying, a one-byte length prefix is ​​appended to each identifier to support boundary identification for variable-length identifiers. After all identifiers are copied, the flow scheduling management process writes a special end marker, such as a sequence of all zero bytes, to the end of the buffer to indicate the end of the current retrieval result data. Simultaneously, the flow scheduling management process updates the write pointer and result availability semaphore corresponding to the buffer, notifying the consumer processes in subsequent steps that new adjacent access point identifier retrieval results are available for reading.

[0035] Step S240: Traverse each retrieved adjacent access point identifier, and query the access point-edge service mapping view again using the adjacent access point identifier as the index key value to obtain the candidate edge computing node identifier bound to each adjacent access point identifier. After deduplicating all candidate edge computing node identifiers, they are collected into a set of adjacent edge computing node identifiers.

[0036] After obtaining the complete list of all adjacent access point identifiers, the flow scheduling management process initiates a traversal loop to query the edge computing node mapping for each adjacent access point identifier in the list. For each adjacent access point identifier, the flow scheduling management process repeats the same process as the first half of steps S210 and S220: using the adjacent access point identifier as the index key, it locates the corresponding key-value entry through the query interface of the access point-edge service mapping view and reads the edge computing node identifier field stored in that entry. Since an access point identifier may be bound to multiple edge computing node identifiers, for example, configuring two edge computing nodes (primary and backup) for a single access point in a high-availability deployment scenario, the query interface may return a list containing multiple identifiers. The flow scheduling management process summarizes the list of edge computing node identifiers retrieved for each adjacent access point identifier into a flat list structure. After traversing all adjacent access point identifiers, the flow scheduling management process performs a deduplication operation on the flat list. The deduplication operation is implemented using a temporarily constructed hash set: Each candidate edge computing node identifier in the tiled list is traversed, its hash value is calculated, and it is checked whether it already exists in the hash set. If it does not exist, the identifier is added to both the hash set and the final result list; otherwise, it is skipped. After the traversal is complete, all identifiers in the final result list constitute the deduplicated set of adjacent edge computing node identifiers.

[0037] Step S250: Take the current service edge computing node identifier as the central node, take each identifier in the set of adjacent edge computing node identifiers as a leaf node, and encapsulate them together with the flow identity tag into a service location candidate set data structure with the flow identity tag as the unique identifier.

[0038] In one implementation, step S250 may specifically include the following steps S251 to S256: Step S251: Allocate a contiguous storage area in memory for constructing the service location candidate set data structure, and write the stream identity tag at a fixed offset at the beginning of the contiguous storage area as the globally unique retrieval key of the data structure.

[0039] The flow scheduling management process first calculates the total storage space required for the service location candidate set data structure. This total size is obtained by summing the fixed header length, the length of the central node information area, and the length of a variable number of leaf node information areas. The fixed header length includes the number of bytes for the flow identity tag field, version number field, creation timestamp field, and central node count field; the central node information area length is the sum of the number of bytes for the central node identifier field and the status flag field; the leaf node information area length is the total number of bytes for the leaf node count field plus the identifier and status flag fields for each leaf node. Using the calculated total size as a parameter, the flow scheduling management process calls the operating system's memory allocation function to request a contiguous storage region from the heap memory. After successful allocation, the flow scheduling management process uses pointer arithmetic to locate the fixed offset at the beginning of the storage region; this offset is zero, which is the starting address of the storage region. The flow scheduling management process then copies the binary value of the flow identity tag to this location verbatim, with the copy length strictly equal to the fixed byte length of the flow identity tag, for example, thirty-two bytes. At this point, the globally unique retrieval key for this data structure is complete, and any process holding a stream identity token can quickly retrieve this data structure from the cache by matching this header field.

[0040] Step S252: After the flow identity tag, write a count value indicating the number of central nodes. Here, the count value is fixed at 1. Then, write the current service edge computing node identifier into the central node identifier field, and then write the central node type identifier to indicate that the node is the current service provider.

[0041] Immediately following the last byte of the Flow Identity field, the flow scheduling management process moves the memory write pointer forward and writes the Central Node Count field at the next byte-aligned position. This field occupies a fixed byte length, such as a four-byte unsigned integer. The flow scheduling management process converts the integer value to 1 using a host byte order to network byte order conversion function before writing it to this position. This count value remains 1 throughout the lifetime of the service location candidate set data structure, indicating that there is one and only one central node. Subsequently, the flow scheduling management process writes the byte sequence of the current service edge computing node identifier immediately after the count field. This identifier is either a variable-length string or a fixed-length identifier, and is processed according to the network byte order specification during writing. After the central node identifier field is written, the flow scheduling management process immediately writes a Central Node Type Identifier field after its last byte. This field is a single-byte or multi-byte enumerated type value, and its value range is jointly defined by the SDN controller and the service location candidate set data structure specification. The flow scheduling management process writes a predefined enumeration value, such as the hexadecimal value 0x01, representing the current service provider into this field to indicate that the central node is actually providing business flow services.

[0042] Step S253: After the center node field is written, the leaf node count field is written next. Its value is the total number of elements in the adjacent edge computing node identifier set. Then, all the identifiers in the adjacent edge computing node identifier set are written sequentially into the consecutively arranged leaf node identifier fields.

[0043] The flow scheduling management process uses the last byte of the central node type identifier field in step S252 as a reference, moves the write pointer to the first byte after it, and begins writing the leaf node count field from there. The leaf node count field uses the same fixed byte length and unsigned integer encoding format as the central node count field. The flow scheduling management process obtains the total number of elements in the adjacent edge computing node identifier set obtained from the deduplication and aggregation in step S240, and writes this total number into the leaf node count field after byte order conversion. Immediately after the count field, the flow scheduling management process allocates an equal-length leaf node identifier field storage slot for each adjacent edge computing node identifier in the set. The length of each storage slot is equal to the maximum byte length of all possible edge computing node identifiers, or uses a variable-length encoding method with a byte length prefix plus a variable-length identifier byte sequence. The flow scheduling management process traverses the adjacent edge computing node identifier set, and copies each adjacent edge computing node identifier to the corresponding storage slot in the order of the set iterator's output, maintaining the relative order between the identifiers during copying, and writing the actual byte length before each identifier in the variable-length encoding method. After all the identifiers have been copied, the contiguous storage areas of the leaf node identifier fields form a compact linear list of leaf node identifiers.

[0044] Step S254: After each leaf node identifier field, append a status flag field and set the initial value of all status flag fields to the first status value representing the standby state. At the same time, set the status flag field after the center node identifier field to the second status value representing the active state.

[0045] The status flag field is a fixed-length metadata field appended to each node identifier field, used to record the current state of the node in the service location candidate set. The status flag value follows a predefined state enumeration: the first status value represents a standby state, indicating that the node has completed service context preparation but has not yet taken over traffic; the second status value represents an active state, indicating that the node is actually carrying service traffic. The status flag field occupies a fixed-length storage space, such as one or two bytes, and its specific binary encoded value is explicitly defined in the protocol specification of the service location candidate set data structure. While writing the leaf node identifier field in step S253, the flow scheduling management process allocates a storage location for a status flag field immediately following each leaf node identifier. The flow scheduling management process creates a constant with a byte value of the first status value, such as 0x00, and writes this constant into the status flag field of all leaf nodes one by one through a loop, completing the initialization of all leaf node states to the standby state. For the central node, the flow scheduling management process moves the write pointer to the storage location of the status flag field reserved after writing the central node identifier in step S252, and writes a second status value representing the active state, such as 0x01, into this field. At this point, the central node is marked as active, and all leaf nodes are marked as standby, with the status semantics consistent with the actual role of the node.

[0046] Step S255: Obtain the current precise time from the SDN controller, convert the current precise time into a timestamp format, write it into the reserved creation timestamp field in the contiguous storage area, and add 1 to the value of the reserved version number field before writing it to complete the version update.

[0047] The SDN controller internally maintains a high-precision time synchronization module. This module synchronizes with an external standard clock source via a network time protocol, providing the current system time with microsecond-level accuracy. The flow scheduling management process calls the module's application programming interface to obtain a time structure containing count values ​​at the second and microsecond or nanosecond levels. The flow scheduling management process converts the obtained time into a standard timestamp format, such as the total number of microseconds or nanoseconds since the Coordinated Universal Time epoch. This format is an eight-byte signed or unsigned integer. After conversion, the flow scheduling management process locates a pre-reserved position in the contiguous storage area for creating the timestamp field. This position is located at a fixed offset in the header area, for example, several bytes immediately following the flow identity tag field. The flow scheduling management process converts the timestamp integer value to network byte order using a byte order conversion function and writes it to this position. Simultaneously, the flow scheduling management process reads the current value of the reserved version number field. The version number field is also located at a fixed offset in the header area and is an unsigned integer occupying two or four bytes, with its initial value cleared when the memory area is allocated. The flow scheduling management process increments this value by 1 and writes the result back to the version number field, completing the version update of the service location candidate set data structure. Each modification operation to this data structure will trigger an increment of the version number, providing a basis for subsequent concurrency control and cache consistency verification.

[0048] Step S256: Convert the starting address of the contiguous storage region into a pointer, encapsulate it together with the stream identity tag into a ready notification message, send it to the stream table shadow construction process through the inter-process communication channel, and reclaim the temporary variables outside the contiguous storage region.

[0049] The Ready Notification Message (BNMessage) is a structured message used by various functional processes within the SDN controller to transmit control information. Its message body includes a message type code, a target process identifier, a flow identity flag, and a pointer to a memory region of a service location candidate set data structure. The flow scheduling management process first converts the starting address of the contiguous storage region requested in step S251 from a memory handle to a generic pointer type. Then, it fills the corresponding field of the BNMessage structure with this pointer value and a copy of the flow identity flag. The inter-process communication channel can be implemented in various ways, such as a lock-free message queue based on a ring buffer, Unix domain sockets, or a message passing mechanism using shared memory and semaphores. The flow scheduling management process calls the channel's sending interface to push the encapsulated BNMessage into the channel, targeting the receiving port registered in the process registry by the flow table shadow construction process. After sending, the flow scheduling management process reclaims the memory temporarily allocated during steps S210 to S255, including the hash table of the initial adjacency set, the hash table of the temporary set, the processed tag bitmap, and various temporary string variables, to ensure effective memory resource reclamation.

[0050] Step S260: Store the service location candidate set data structure in the global location cache of the SDN controller, and send a ready notification carrying the memory address of the service location candidate set data structure to the flow table shadow construction process.

[0051] The global location cache is a centralized storage component maintained internally by the SDN controller process, specifically designed to store the service location candidate set data structure corresponding to all active service flows. This cache employs a hash table-based key-value storage structure, using the flow identity tag as the key and a pointer to the starting address of the memory region of the service location candidate set data structure as the value. The flow scheduling management process calls the global location cache's insertion interface, passing in the flow identity tag and the starting pointer of the memory region requested in step S251. The insertion interface first searches the cache to confirm whether a record with the same flow identity tag already exists. If it does, it performs a replacement update and releases the memory occupied by the old data structure; otherwise, it directly inserts the key-value pair into the hash table. Subsequently, the flow scheduling management process constructs a ready notification message with the same format as in step S256, carrying the memory address of the service location candidate set data structure and the flow identity tag in the message body, and sends it to the flow table shadow construction process through the inter-process communication channel. The arrival of this ready notification message triggers the flow table shadow construction process to start the subsequent flow table pre-installation process.

[0052] Step S300: Send a flow table shadow construction instruction carrying the flow identity tag and service location candidate set to the SDN controller, so that the SDN controller creates a primary flow table entry pointing to the current service edge computing node identifier for the flow identity tag at the first switch connected to the current access point, and creates a corresponding shadow flow table entry for each adjacent edge computing node identifier in the service location candidate set. Each shadow flow table entry has a lower priority than the primary flow table entry and is initially in a dormant state.

[0053] In one implementation, step S300 may specifically include the following steps S310 to S360: Step S310: The SDN controller receives the flow table shadow construction instruction, parses out the flow identity tag and service location candidate set, extracts the current service edge computing node identifier from the service location candidate set, obtains the destination network address of the node in the SDN data plane, and writes the destination network address into the main action instruction set.

[0054] The SDN controller's flow table management core module listens for flow table shadow construction instructions from the flow table shadow construction process in its instruction receiving thread. Upon receiving the instruction message, the parsing module first reads the fixed header in the message body, confirms the message as a flow table shadow construction instruction based on the message type code, and then reads the value of the flow identity tag field from a specified offset position in the message body according to the predefined message structure layout. Simultaneously, it reads a memory pointer or serialized data block from another specified offset position to obtain the content of the service location candidate set. If the service location candidate set is transmitted in the form of a memory pointer, the parsing module directly accesses the data structure constructed in step S250 through the pointer, locates the central node identifier field according to the layout defined in steps S251 to S253, and reads the current service edge computing node identifier. Subsequently, the SDN controller's topology and address resolution module uses this node identifier as an index to query its internally maintained edge computing node address resolution table. This address resolution table stores the mapping relationship between each edge computing node identifier and its destination network address used in the SDN data plane. The destination network address may be an Internet Protocol address or a Media Access Control address. After a successful query, the flow table management core module creates a primary action instruction set data structure. This structure contains an action type field and an action parameter field. The action type field is filled with the opcode representing the rewriting of the packet's destination address, and the action parameter field is filled with the destination network address obtained from the query.

[0055] Step S320: Create a prototype of the primary flow table entry in the flow table construction memory area, write the flow identity tag into the matching field of the primary flow table entry prototype in an exact match manner, and write the primary action instruction set and the priority field representing the normal priority into the action field and attribute field of the primary flow table entry prototype.

[0056] The flow table construction memory area is a dedicated working memory region allocated by the SDN controller for the flow table entry generation process. The data structures within this area simulate the complete layout of the switch's hardware flow table entries. The primary flow table entry prototype is a flow table entry data structure instance temporarily stored in the flow table construction memory area, awaiting encapsulation into a formal flow table installation request and its delivery to the switch. The flow table management core module, following the binary format specification of switch flow table entries, divides the primary flow table entry prototype into three areas: a matching field, an action field, and an attribute field. For the matching field, the module copies the complete byte sequence of the flow identity tag to a specified offset position in the matching field and sets the type indicator of the matching field to an exact match type, requiring the corresponding field of the packet to be completely identical to the flow identity tag for a match to occur. For the action field, the module serializes the primary action instruction set constructed in step S310 and copies it to the action field's storage area. For the attribute field, the module first locates the priority subfield, writes the predefined normal priority constant value of the SDN controller (e.g., 200) after byte order conversion, and writes it to the other subfields of the attribute field. Simultaneously, it writes default values ​​to the idle timeout and hard timeout fields, setting them to zero to indicate that the timeout will never expire. Based on this, the prototype of the primary flow table entry is completed. Its semantics are: when the switch receives a packet whose matching field equals the flow identity tag, it hits this flow table entry with normal priority, rewrites the packet's destination address to the destination network address corresponding to the current serving edge computing node identifier, and forwards it.

[0057] Step S330: Traverse each adjacent edge computing node identifier in the service location candidate set, query the destination network address corresponding to each adjacent edge computing node identifier, construct a shadow flow table entry prototype for each destination network address, write the flow identity tag into the matching field of each shadow flow table entry prototype, but write the corresponding destination network address into its action field, and fill in a shadow priority value that is significantly lower than the normal priority into its priority field.

[0058] The flow table management core module reads the leaf node identifier linear table constructed in step S253 from the service location candidate set, obtains a list of all adjacent edge computing node identifiers, and then starts a traversal loop. For each adjacent edge computing node identifier, the module performs an address resolution process similar to that in step S310, using the adjacent edge computing node identifier as an index to query the edge computing node address resolution table and obtain the corresponding destination network address. Subsequently, the module allocates a new flow table entry prototype storage slot for the adjacent edge computing node identifier in the flow table construction memory area and begins constructing a shadow flow table entry prototype. For the matching field of the shadow flow table entry prototype, the module uses the exact same method as in step S320, copying the flow identity tag to the corresponding position of the matching field with an exact match type. For the action field, the module sets the action type to the packet destination address rewrite opcode and writes the destination network address corresponding to the adjacent edge computing node identifier obtained from the address resolution table as the action parameter. For the priority subfield of the attribute field, the module writes a predefined shadow priority constant value, such as 10, after byte order conversion. The shadow priority value is designed to be strictly lower than the normal priority value to ensure that when multiple flow table entries with the same matching domain exist on the switch, the primary flow table entry with higher priority is always hit first, while the shadow flow table entry may only be hit when the primary flow table entry fails or is removed. The process management core module repeats the above construction process for each adjacent edge computing node identifier until all leaf node identifiers in the service location candidate set have generated corresponding shadow flow table entry prototypes.

[0059] Step S340: Set an initial state flag for each shadow flow table entry prototype, set the initial state flag to a dormant state representing that the rule exists but does not participate in data plane matching, and append a zero-value hit counter to the statistics field of each shadow flow table entry prototype.

[0060] In one implementation, step S340 may specifically include the following steps S341 to S346: Step S341: Access the shadow flow table entry state definition library maintained by the SDN controller, retrieve the predefined dormant state state code from the state definition library. The dormant state state code is mutually exclusive with the active state state code, and in the flow table entry matching pipeline, flow table entries with a dormant state will be automatically skipped by the hardware lookup engine.

[0061] The shadow flow table entry state definition library is a static configuration database within the SDN controller. This database stores the mapping relationship between all possible flow table entry state names and their encoded values ​​in key-value pairs. The state code is a binary control word that the switch hardware can recognize, typically stored in an auxiliary control unit within a tri-state content-addressable memory. The flow table management core module calls the state definition library's query interface, passing in a string constant or enumerated value representing the dormant state. The query interface locates the corresponding database entry through hash lookup or direct indexing and returns the binary state code for that dormant state, such as an 8-bit or 16-bit control word. According to the state definition library specification, the dormant state code and the active state code are mutually exclusive in terms of bits; that is, the logical AND operation between the two results in 0. In addition, the flow entry matching pipeline is a high-speed packet processing data path inside the switch hardware. This data path integrates a hardware lookup engine. When comparing flow entries one by one, the engine will first read the status code of each flow entry. If the status code is found to be equal to the dormant status code, the entry will be skipped through the gating circuit and no matching result will be generated. This behavior is equivalent to the entry being temporarily masked in the matching sequence.

[0062] Step S342: Write the retrieved dormant state status code into the reserved status control field in the shadow flow table entry prototype, and write a control bit to disable interruption in the reserved bit of the status control field to prevent the dormant flow table entry from generating an interrupt signal when it is accessed unexpectedly.

[0063] The prototype shadow flow table entry reserves a fixed-length status control field in the extended area of ​​its attribute field. This field consists of multiple bits, with the lower bits being status encoding bits and the higher bits being reserved control bits. The flow table management core module writes the status code of the sleep state retrieved in step S341 into the corresponding status encoding bit range of the status control field through masking and shifting operations. For example, if the sleep state code is hexadecimal value 0x0F, the lower eight bits of the status control field are used to store the status code, and the module writes 0x0F into these lower eight bit positions. Simultaneously, the module locates a specific reserved bit in the status control field, which is assigned to disable interrupt hits. The hardware manual specifies that when this bit is written to 1, even if the flow table entry is accidentally matched due to some hardware anomaly, the switch's interrupt controller will not send an interrupt signal to the central processing unit. The module sets this reserved bit to 1 through bit operations, thereby ensuring that the shadow flow table entry in the sleep state will not interfere with the switch control plane under any circumstances.

[0064] Step S343: After writing the status code of the hibernation state, append a wake-up token field to the extended attribute area of ​​the shadow flow table entry prototype, and fill the field with a randomly generated wake-up token value. The wake-up token will serve as the only credential for switching from the hibernation state to the active state.

[0065] The extended attribute area is a variable-length additional storage area in the shadow flow table entry prototype, located after the standard matching field, action field, and attribute field. It stores custom extended attributes for flow table entries. The wake-up token field is a specific field within the extended attribute area; its offset and length are uniformly specified in the service location candidate set data structure and the flow table entry prototype's construction specification. The flow table management core module calls the SDN controller's secure random number generation module. This module uses a cryptographically secure pseudo-random number generator, for example, by reading a hardware random number seed and executing a hash deterministic random bit generation algorithm, to generate a random bit sequence with sufficient entropy as the wake-up token value, such as a 32-byte random number. The module fills the complete binary sequence of this wake-up token value into the wake-up token field of the shadow flow table entry prototype. This wake-up token is unique and unpredictable; any subsequent operation attempting to switch this shadow flow table entry from a dormant state to an active state must provide a wake-up token value exactly the same as written here, thus preventing unauthorized flow table entry activation.

[0066] Step S344: Upload the wake-up token value and the identifier of the shadow flow table entry prototype to the wake-up token mapping table of the SDN controller. The wake-up token mapping table stores the corresponding wake-up token value using the combination of the flow identity tag and the edge computing node identifier as an index.

[0067] The wake-up token mapping table is a global security association table maintained by the SDN controller. This table is organized using a composite index structure. Its primary index key is a combination of the flow identity tag and the edge computing node identifier, and its key value is the wake-up token value corresponding to this combination key. After generating and writing the wake-up token in step S343, the flow table management core module constructs a composite key data structure. It sequentially concatenates the currently processed flow identity tag and the adjacent edge computing node identifier corresponding to the prototype of the shadow flow table entry. Then, using this composite key as an index, it calls the insertion interface of the wake-up token mapping table to store the wake-up token value of the prototype of the shadow flow table entry into the mapping table. The insertion interface can be implemented using a hash table-based key-value storage. The hash function calculates the complete byte sequence of the composite key, resolving hash collisions using chaining or open addressing. The establishment of this mapping table enables the SDN controller to retrieve the correct wake-up token using the flow identity tag and the target edge computing node identifier when it needs to actively wake up a shadow flow table entry.

[0068] Step S345: Before the SDN controller sends the shadow flow table entry prototype to the first switch, the integrity of the shadow flow table entry prototype is verified to ensure that the status control field and wake-up token field have been correctly written and are consistent with the records in the wake-up token mapping table.

[0069] Before submitting the shadow flow table entry prototype to the distribution queue, the core module of the flow table management performs a systematic integrity verification process. The verification process first reads the status control field in the shadow flow table entry prototype's memory image, verifying whether its value equals the sleep state status code retrieved in step S341, and whether the interrupt control bit to prevent hits is set. Then, the verification process reads the wake-up token field in the extended attribute area of ​​the shadow flow table entry prototype to obtain the written wake-up token value. Simultaneously, the verification process constructs a composite key using the flow identity tag and adjacent edge computing node identifier corresponding to the shadow flow table entry prototype, performs a lookup operation in the wake-up token mapping table, and reads the wake-up token value recorded in the mapping table. The verification process compares the wake-up token value directly read from the shadow flow table entry prototype with the wake-up token value retrieved from the mapping table byte by byte. If all bytes are consistent, it is determined that the field has been correctly written and is consistent with the central record. The verification process also performs format compliance checks on the matching field and action field in the shadow flow table entry prototype to ensure that the field length and encoding format conform to the southbound interface protocol specifications. If any validation fails, the validation process will halt the distribution of the shadow flow table entry prototype and generate an alarm record containing detailed error codes.

[0070] Step S346: After verification, lock the configuration of the shadow flow table entry prototype, submit the locked shadow flow table entry prototype to the distribution queue, and wait for batch installation.

[0071] After successful verification, the flow table management core module performs a locking operation on the shadow flow table entry prototype. The locking operation is achieved by setting a read-only flag in the flow table entry prototype's memory block. This flag triggers the memory management unit's protection mechanism, prohibiting any process from writing to the prototype's memory area. The locked shadow flow table entry prototype is then converted to a read-only data structure. Subsequently, the flow table management core module pushes the memory address pointer of the locked shadow flow table entry prototype into a first-in-first-out (FIFO) or priority-ordered distribution queue. The distribution queue is a producer-consumer shared data structure between the SDN controller's southbound interface driver layer and the flow table management core module, implemented using a lock-free or mutex-protected circular buffer. After pushing the prototype into the queue, the flow table management core module notifies the southbound interface sending thread of a new task arriving via a semaphore or condition variable, awaiting batch encapsulation and installation in step S350.

[0072] Step S350: Encapsulate the primary flow table entry prototype and all shadow flow table entry prototypes together into a flow table batch installation request, and send the flow table batch installation request to the first switch through the southbound interface of the SDN controller.

[0073] In one implementation, step S350 may specifically include the following steps S351 to S356: Step S351: Count the total number of flow table entries to be installed this time. Add the number of primary flow table entry prototypes to the number of all shadow flow table entry prototypes to get the total number of installation entries. Write the total number of installation entries into the count field of the header of the flow table batch installation request.

[0074] The header of the flow table batch installation request is a fixed-format message header structure, containing a version number field, a message type field, a total message length field, and a flow table entry count field. The flow table management core module maintains an installation item counter, initially set to 0. The module iterates through the primary flow table entry prototype built in step S320 and all shadow flow table entry prototypes built in step S330, incrementing the counter by 1 for each prototype. The final counter value is the total number of installation items. For example, if the service location candidate set contains one current service edge computing node identifier and three adjacent edge computing node identifiers, then the number of primary flow table entry prototypes is 1, the number of shadow flow table entry prototypes is 3, and the total number of installation items is 4. The module converts this total number of installation items from host byte order to network byte order and writes it into the reserved count field position in the flow table batch installation request header.

[0075] Step S352: Calculate the total byte length required for the entire flow table batch installation request, request a contiguous memory block matching the total byte length from the southbound interface transmission buffer managed by the SDN controller, and if the request fails, enter a backoff wait and re-request after waiting.

[0076] The total byte length consists of three parts: a fixed request header length, the total number of flow table entries multiplied by the serialization length of a single flow table entry prototype, and the length of the tail batch operation type code. The flow table management core module calculates this based on the various length constants defined in the southbound interface protocol specification. The serialization length of a single flow table entry prototype is a fixed value defined in the specification, covering all bytes of the matching field, action field, attribute field, and extended attribute area. After calculation, the module initiates a memory block allocation request to the southbound interface transmission buffer manager, with the calculated total byte length as the request parameter. The transmission buffer manager is part of the SDN controller's southbound interface driver and manages a pre-allocated contiguous physical memory pool. The manager first searches the free memory block list for the first free block greater than or equal to the requested size. If found, it performs a splitting operation, marks the matching block as allocated, and returns its starting address. If there are no sufficiently large free blocks, it indicates that the buffer is temporarily exhausted, and the manager returns an allocation failure. Upon receiving an allocation failure, the module does not immediately retry but initiates a backoff waiting process. The backoff waiting uses a binary exponential backoff algorithm: initially wait for a basic time unit, such as ten milliseconds; if it fails again, the waiting time is doubled to twenty milliseconds, and so on, until allocation is successful or the maximum number of retries is reached.

[0077] Step S353: Following the order of primary flow table entry prototype first and then shadow flow table entry prototype, copy the complete binary representation of each flow table entry prototype to the allocated contiguous memory block in sequence, and separate the binary representations of each flow table entry prototype with a predefined delimiter.

[0078] After successfully allocating a contiguous block of memory, the flow table management core module begins the serialization copy operation. The module maintains a write pointer, initially pointing to the first byte after skipping the request header in the contiguous memory block. First, the module processes the primary flow table entry prototype, calling its serialization method to convert all its fields into a contiguous byte sequence according to the binary format specified by the southbound interface protocol. The serialization method reads the value of each subfield in the order of matching field, action field, and attribute field, assembling it into a complete binary representation of the flow table entry through bit shifting and masking operations. This binary representation is copied entirely to the position currently pointed to by the write pointer, and the write pointer is incremented by the length of the binary representation after the copy is complete. Next, the module copies a set of predefined delimiter byte sequences to the write pointer position. The delimiters are typically a set of special magic numbers, such as the four-byte hexadecimal sequence 0xA1B2C3D4, used to assist the receiver in detecting flow table entry boundaries when byte alignment errors occur. The write pointer is incremented again by the length of the delimiters. Subsequently, following the order in which the shadow flow table entry prototypes were constructed in step S330, the module retrieves each shadow flow table entry prototype one by one, repeats the above serialization and copying process, and inserts a delimiter between the binary representations of every two shadow flow table entry prototypes. After all prototypes have been copied, the module does not append any new delimiters after the last delimiter.

[0079] Step S354: Append a batch operation type code to the end of the contiguous memory block. The batch operation type code instructs the first switch to atomically write all flow table entries in this request to its flow table hardware storage, ensuring that either all writes are successful or all are rolled back.

[0080] The batch operation type code is an enumeration value defined in the southbound interface protocol, used to instruct the switch how to install a batch of flow table entries into the hardware. The flow table management core module moves the write pointer to the first byte after all flow table entry prototypes and delimiter sequences, and writes a predefined type code representing an atomic batch write operation, such as the hexadecimal value 0x02, after byte order conversion, to this location. The meaning of atomic batch write is that the switch must treat the installation of this group of flow table entries as a transaction. The transaction is only committed when all flow table entries are successfully written to the hardware flow table storage slot. If any flow table entry write fails, the switch must roll back all written flow table entries, restoring the flow table state before the batch installation request was executed. After the module completes the type code writing, it updates the total message length field in the header of the contiguous memory block to the current actual offset value of the write pointer, ensuring that the total length field accurately reflects the actual length of the entire request.

[0081] Step S355: Call the batch write function of the southbound interface, pass in the starting address and total byte length of the contiguous memory block as parameters, and push the data to the management agent process of the first switch through the batch installation protocol of the flow rules of the southbound interface.

[0082] The batch write function for the southbound interface is a core application programming interface provided by the southbound interface driver layer of the SDN controller. This function encapsulates the specific details of the underlying transport protocol. The flow table management core module calls this function, passing in the starting address of the contiguous memory block obtained in step S352 and the total message length updated in step S354. Internally, the batch write function first verifies the validity of the input parameters, and then, based on the connection status of the first switch, obtains a socket descriptor pointing to a Transmission Control Protocol (TCP) connection or a Transport Layer Security (TLS) encrypted connection for that switch from the connection pool. If no connection is currently available, the function triggers a connection reconstruction process. Following the flow rules for batch installation of the protocol, the function treats the entire contents of the contiguous memory block as a complete protocol data unit and pushes it to the management agent process of the first switch via the socket interface's send call. During the sending process, the function may enable the TCP segmentation offloading function to improve efficiency and monitor the occupancy of the send buffer for flow control.

[0083] Step S356: Start a timeout retransmission timer and wait for the first switch to respond to the batch installation request. If a batch installation confirmation is received before the timer expires, the installation status of each item in the confirmation content is parsed. If the timeout occurs, the overall retransmission process is triggered.

[0084] The timeout retransmission timer is a timer object maintained by the SDN controller for each request sent to the switch, used to detect request loss or switch unresponsiveness. After the send call in step S355 returns, the flow table management core module immediately creates a timer instance, sets the timeout duration to a preset value, such as one second, and registers a timer callback function. Then, the module enters a blocking or asynchronous waiting state, listening for southbound interface response messages from the first switch. If the module receives a flow table batch installation confirmation message from the first switch before the timer expires, the module first cancels the timeout retransmission timer and then parses the content of the confirmation message. The format of the confirmation message corresponds to the request message format, containing an overall status code and a separate installation result entry for each flow table entry prototype. Each entry contains a flow table entry index and an installation status code, indicating whether the installation of the flow table entry was successful and the specific reason for failure. The module parses all installation result entries one by one, checking for any failure status codes. If the timer times out before receiving a response, the timer callback function is invoked. In this callback function, the flow table management core module marks this transmission as a timeout failure and pushes the entire contiguous memory block of the request back into the retransmission queue. The retransmission queue then manages the subsequent complete retransmission process. The retransmission process will be re-executed according to the complete steps S352 to S355 until a successful acknowledgment is received or the maximum number of retransmissions is reached.

[0085] Step S360: Receive the batch installation confirmation returned by the first switch. The batch installation confirmation corresponds to the installation result of each flow table entry prototype. After confirming that all installations are successful, send an installation completion notification carrying the flow identity tag and all shadow flow table entry identifiers to the service status synchronization module.

[0086] After confirming the successful installation of all flow table entries in step S356, the flow table management core module releases the contiguous memory block allocated in step S352 and returns it to the southbound interface transmission buffer manager. Subsequently, the module constructs an installation completion notification message. The message body of this message includes a flow identity marker field, a primary flow table entry identifier field, and a shadow flow table entry identifier list field. The primary flow table entry identifier is the hardware flow table entry index number corresponding to the primary flow table entry prototype returned by the first switch during batch installation confirmation. The shadow flow table entry identifier list contains a sequence of hardware flow table entry index numbers corresponding to all shadow flow table entry prototypes returned during batch installation confirmation. The module sends this installation completion notification message to the service state synchronization module through the SDN controller's internal inter-process communication mechanism, such as a message bus or event notification channel. Upon receiving this notification, the service state synchronization module knows that the pre-deployment at the flow table level has been completed and immediately initiates the service state synchronization process in step S400, collaboratively advancing the compute service and network service to the switchover-ready state.

[0087] Step S400: After the first switch completes the installation of all shadow flow table entries, it sends a service status synchronization instruction carrying a flow identity tag to all edge computing nodes in the service location candidate set. The service status synchronization instruction instructs each edge computing node to synchronize the service context associated with the flow identity tag from the current service edge computing node according to the flow identity tag, and sets the synchronized service context to the pending activation state.

[0088] In one implementation, step S400 may specifically include the following steps S410 to S460: Step S410: Using the current service edge computing node identifier in the service location candidate set as the context data source, query the service context directory of the node, extract the storage location offset and data length of the process memory image, network connection state snapshot and session key material associated with the flow identity tag, and form a context data block list.

[0089] The service context directory is a local index table maintained by the service agent process running on each edge computing node. This index table records the mapping relationship between the flow identity tags of all active service instances on the node and their context data storage locations. A process memory image refers to a complete copy of the entire user-space virtual memory region of a service process at a certain checkpoint, including the contents of the code segment, data segment, heap, and stack. A network connection state snapshot refers to the state information of the transmission control protocol connection associated with the service flow, including the values ​​of protocol stack variables such as the currently used send sequence number, receive acknowledgment number, congestion window size, and slow start threshold. Session key material refers to the private key portion of the symmetric session key or asymmetric key pair used to encrypt the communication content of this service flow. Storage location offset refers to the offset of the starting address of the above-mentioned context data types in the local persistent storage or shared memory area of ​​the edge computing node relative to the allocation base address. Data length refers to the number of consecutive bytes occupied by each type of context data.

[0090] During operation, the service state synchronization module targets the central node identifier (i.e., the current service edge computing node identifier) ​​recorded in the service location candidate set and sends a context directory query request to the service agent process on that node via a secure channel. The request parameter is the flow identity tag. Upon receiving the request, the service agent process performs a precise search in its service context directory. After locating the directory entry corresponding to the flow identity tag, it reads out the process memory image storage location offset and data length, network connection state snapshot storage location offset and data length, and session key material storage location offset and data length recorded in that entry, encapsulates them into a context data block list message, and replies to the service state synchronization module. The context data block list is a list structure, where each list element is a data block descriptor. The data block descriptor contains three fields: data block type, remote memory address, and data length.

[0091] Step S420: For each adjacent edge computing node identifier in the service location candidate set, generate an independent data retrieval task. The data retrieval task includes the network address of the context data source, the context data block list, and a target node write address.

[0092] The service status synchronization module iterates through the leaf node identifier list of the service location candidate set and initiates a parallel task generation process for each adjacent edge computing node identifier. For each adjacent edge computing node identifier, the module first queries the node address resolution table to obtain the network address of the adjacent edge computing node. Then, it pre-allocates an isolated memory region for the flow identity tag on the service agent process of the adjacent edge computing node and obtains the base address of the isolated memory region as the target node write address. The allocation process is completed by sending a memory allocation request message to the adjacent edge computing node. This request message carries the flow identity tag and the total size of the required memory, which is obtained by summing the lengths of all data in the context data block list in step S410. After receiving the request, the service agent process of the adjacent edge computing node calls the operating system's memory allocation function to request a contiguous virtual memory region that meets the size requirement and replies with the base address of the region to the service status synchronization module. After obtaining the target node's write address, the module constructs a complete data retrieval task data structure for the current adjacent edge computing node identifier. This data structure contains three core fields: the network address corresponding to the current service edge computing node identifier as the data source address; a copy of the context data block list obtained in step S410; and a mapping table of the base address of the target node's write address and the corresponding data block offset.

[0093] Step S430: Send all generated data retrieval tasks one by one to the corresponding adjacent edge computing nodes. Each data retrieval task instructs the receiving node to actively initiate a one-sided read operation based on remote direct memory access to the current service edge computing node to retrieve all data blocks listed in the context data block list in a zero-copy manner.

[0094] In one implementation, step S430 may specifically include the following steps S431 to S436: Step S431: The receiving node parses the data retrieval task, obtains the network address and context data block list of the current service edge computing node, and reads a data block descriptor in sequence from the context data block list. The data block descriptor contains the remote memory address, the local memory address, and the data length.

[0095] Upon receiving a data fetch task message, the service agent process of the receiving node (i.e., the adjacent edge computing node) calls the task parsing function to deserialize the message payload. The parsing function first reads the length and content of the network address field from the message header according to the message format specification, parsing out the network address of the current service edge computing node. This address is an Internet Protocol address that supports Remote Direct Memory Access (RDA). Subsequently, the parsing function reads the context data block list field, which contains an integer representing the number of data block descriptors, followed by a sequence of that number of data block descriptors. Each data block descriptor contains three values ​​in sequence: remote memory address, local memory address, and data length. The parsing function constructs an array or linked list of data block descriptors in memory, storing all descriptors in the list sequentially. This task parsing process is completed in the user-space process of the receiving node, without involving kernel system calls, to minimize the startup latency of the subsequent fetch process. After parsing, the receiving node maintains a data block descriptor traversal pointer, initialized to point to the first data block descriptor in the list.

[0096] Step S432: The network interface controller of the receiving node assembles a remote direct memory access read request message based on the remote memory address and the network address of the current service edge computing node, and sends the message directly to the network interface controller of the current service edge computing node through a priority queue. The entire process does not go through the operating system kernel network stack of the receiving node.

[0097] The service agent process of the receiving node invokes a one-sided read operation primitive through the Remote Direct Memory Access (RDA) verb application programming interface. This primitive accepts three core parameters: the network address of the current service edge computing node, the remote memory address, the local memory address, and the data length. The values ​​of these four parameters are all taken from the current data block descriptor read in step S431. The library function of the verb application programming interface interacts directly with the driver queue of the network interface controller in user space, filling the above parameters into the corresponding fields of a RDA job request structure and submitting the job request to the sending queue. The network interface controller retrieves the job request from the sending queue using either polling or interrupt methods, and assembles a read request message conforming to the RDA protocol specification internally based on the request parameters. The header of this message contains the opcode "read request," the target node address (the network address of the current service edge computing node), and the target memory address (the remote memory address). After the message is assembled, the network interface controller immediately sends the read request message to the physical link through its internal priority queue scheduler. The whole process completely bypasses the operating system kernel network protocol stack of the receiving node and does not generate data copying of the socket buffer.

[0098] Step S433: After receiving the remote direct memory access read request message, the network interface controller of the current service edge computing node parses out the remote memory address, reads the corresponding data directly from the local physical memory, assembles it into a remote direct memory access read response message, carries the data length and the actual data load, and sends it back to the receiving node unilaterally.

[0099] When the network interface controller of the current service edge computing node detects a remote direct memory access read request packet on its physical port, its hardware parsing engine first verifies the validity and integrity of the packet, checking whether the cyclic redundancy check (CRC) code and connection context match. After successful verification, the parsing engine extracts the remote memory address field and the requested data length field from a fixed offset in the packet. Subsequently, the network interface controller's direct memory access engine is triggered. This engine generates a memory read transaction on the peripheral component interconnect standard bus based on the remote memory address, directly initiating a read request to the local physical memory controller to read the specified length of data from the corresponding physical address. This memory read transaction is completed entirely under the control of the network interface controller hardware, without generating an interrupt notification to the local CPU. After the data is read, the network interface controller uses the read data block as the payload, adds the header of the remote direct memory access read response packet (containing the opcode "read response," the identifier of the original request, and the actual returned data length), encapsulates it into a complete response packet, and unilaterally sends it back to the requesting receiving node's network interface controller via the physical link.

[0100] Step S434: After receiving the read response message, the network interface controller of the receiving node writes the data payload directly to the memory location corresponding to the address through the direct memory access engine according to the local memory address carried in the message. After the write is completed, the completion counter is incremented by one.

[0101] Upon receiving a read response message, the network interface controller (NIC) of the receiving node extracts the original request identifier from the message using its hardware parsing engine. Based on this identifier, it looks up the corresponding request context in its incomplete request tracking table. The request context records the local memory address specified when the original request was submitted. The NIC's Direct Memory Access (DMI) engine then initiates a memory write transaction on the Peripheral Component Interconnect (PCIe) bus based on this local memory address, writing the data from the read response message payload byte-by-byte to the physical memory location corresponding to that local memory address. Because this write operation bypasses the CPU and directly modifies the application process's virtual memory region, zero-copy data transfer is achieved. After the write transaction is complete, the NIC internally increments a completion counter associated with the original request. This completion counter is a hardware register, and its value can be read by the user-mode process through the completion polling function of the API.

[0102] Step S435: The control process of the receiving node polls the completion counter. When the value of the completion counter is equal to the total number of data block descriptors in the context data block list, it is determined that all data blocks have been successfully fetched, and the data block consistency verification process is triggered.

[0103] After submitting remote direct memory access read requests corresponding to all data block descriptors in the context block list, the service agent process of the receiving node enters a polling wait loop. This process calls the completion polling function of the application programming interface (API), which checks the current accumulated total value of the completion counter in the network interface controller hardware. The service agent process compares this total value with the total number of data block descriptors in the context block list. If the total value is less than the total number, it means that some read request responses have not yet been returned, and the service agent process briefly yields the CPU before continuing polling. If the total value equals the total number, it means that all remote direct memory access read requests have been successfully completed, and all data blocks have been completely written to the pre-allocated isolated memory region in step S420. At this point, the service agent process exits polling and immediately triggers a data block consistency check process. This verification process performs integrity checks on each written data block. Typically, the data block content is input into a cyclic redundancy check engine or a message digest algorithm engine, and the calculation result is compared with the expected check value that may be carried in the context data block list. Alternatively, the data block's binary format is parsed for compliance to confirm that the data has not been corrupted during transmission.

[0104] Step S436: If a remote direct memory access read request times out or returns an error during the retrieval process, the receiving node initiates a retransmission request for the data block descriptor and sends the retransmission request to the current service edge computing node until the data block is successfully retrieved or the preset maximum number of retransmissions is reached.

[0105] During the polling process in step S435, the service agent process simultaneously monitors the completion status of each remote direct memory access read request. The network interface controller maintains a status field for each work request, including statuses such as normal completion, timeout failure, and returned error code. The service agent process scans the status of all submitted work requests through the error handling function of the application programming interface. If a work request is found to have a timeout status, indicated by the completion counter of the request not incrementing within the predetermined timeout window, the service agent process marks the data block descriptor corresponding to the work request as a retransmission object and re-executes the remote direct memory access read request submission process in step S432 for that descriptor separately. If a work request returns an error code, such as a remote memory address access violation or connection context loss, the service agent process first checks the error type; if it is a retryable error, it also initiates retransmission. Each time a retransmission occurs, the service agent process increments the retransmission count field. If the value of the retransmission count field reaches the system's pre-configured maximum retransmission threshold, such as three times, and the retransmission still fails, the service agent process determines that the data block retrieval has permanently failed, terminates the entire service state synchronization process, and sends a synchronization failure error report to the service state synchronization module, along with the failed stream identity tag, target node identifier, and failed data block descriptor.

[0106] Step S440: Within each adjacent edge computing node, the process memory image, network connection state snapshot, and session key material pulled from the current serving edge computing node are written into the isolated memory area pre-allocated for the stream identity tag, and the written data blocks are verified for consistency.

[0107] The remote direct memory access write process in steps S430 and S434 has directly written the data to the isolated memory region pre-allocated in step S420. After confirming that all data blocks have been fetched, the service agent process performs a full data block consistency check. For process memory image data blocks, the check process verifies whether the magic number and total length fields embedded in the memory image header match the actual number of bytes fetched. For network connection state snapshot data blocks, the check process verifies whether the sequence number and acknowledgment number values ​​are within the valid sequence number space by parsing the protocol control block field in the snapshot structure, and checks whether the combination of each status flag bit conforms to the requirements of the transmission control protocol state machine. For session key material data blocks, the check process verifies whether the key material meets the predefined key format, such as whether the key length is equal to the key length of a specific encryption algorithm, and whether the key entropy value detection passes. After all checks pass, the service agent process marks the data integrity check result of the isolated memory region corresponding to the stream identity tag as passed in the local record, allowing subsequent correction and activation operations.

[0108] Step S450: After the consistency check passes, each adjacent edge computing node silently corrects the network connection state it pulls based on the transmission control protocol sequence number and acknowledgment number in the network connection state snapshot, so that the network connection state is smoothly migrated to the protocol stack of this node.

[0109] In one implementation, step S450 may specifically include the following steps S451 to S456: Step S451: Extract the protocol control block from the network connection state snapshot that has completed the consistency check, locate the send sequence number field and receive acknowledgment number field stored in the protocol control block, read the current values ​​of these two fields and back them up to local temporary variables respectively.

[0110] The protocol control block (PCB) is a data structure in the operating system kernel used to maintain the complete state of each transmission control protocol (TDC) connection. It contains all sequence space variables, congestion control parameters, timer information, and socket status flags at both the sending and receiving ends. After the consistency check in step S440 passes, the service agent process of the adjacent edge computing node parses the network connection state snapshot written to the isolated memory region. The parsing process follows the known memory layout of the PCB, which is defined in the operating system's kernel header file. The parsing code first calculates the byte offset of the send sequence number field in the PCB, reads a 32-bit unsigned integer value from the corresponding position in the snapshot using a memory offset read operation, uses this as the current value of the send sequence number, and copies it to a local temporary variable. Subsequently, the parsing code calculates the offset of the receive acknowledgment number field in the same way, reads its value, and copies it to another local temporary variable. These two temporary variables will serve as the base input for subsequent correction operations.

[0111] Step S452: Query the current state of the socket buffer pre-allocated for the identity tag of the stream in the kernel of the adjacent edge computing node, obtain the sequence number of the last byte confirmed by the local protocol stack, and use it as the local maximum acknowledgment number.

[0112] The socket buffer is a receive and send buffer memory area attached to a socket structure pre-created by the operating system kernel of the adjacent edge computing node in step S420 for the stream identity tag. This socket is not bound to any network connection state at creation. The service agent process reads the protocol control block structure corresponding to the socket from the kernel memory through system call interfaces provided by the operating system, such as system calls to obtain socket options, or directly through a preloaded kernel module. After reading the protocol control block, the service agent process locates the position of the confirmation-related variables stored internally and obtains the sequence number value of the last byte confirmed by the local protocol stack on this socket, i.e., the largest byte sequence number that the receiver has successfully received and delivered to the application layer in order from the perspective of the local protocol stack. This value is usually an initial sequence number value in the initial state of the pre-allocated socket buffer, which is generated by the operating system using a secure random number generator when the socket is created.

[0113] Step S453: Compare the received acknowledgment number read from the snapshot with the local maximum acknowledgment number. If the received acknowledgment number is greater than the local maximum acknowledgment number, update the acknowledgment status record of the local protocol stack to keep it consistent with the received acknowledgment number, and adjust the left boundary of the receiving window.

[0114] The service agent process performs an integer comparison operation, comparing the received acknowledgment number read from the snapshot with the local maximum acknowledgment number obtained in step S452. The comparison operation is completed using comparison instructions from the CPU, and the result is determined by condition flags. If the comparison result shows that the received acknowledgment number is greater than the local maximum acknowledgment number, it means that the receiving end of this connection on the current service edge computing node has acknowledged more bytes, and this state must be synchronized to the local protocol stack. The service agent process calls the protocol control block update function provided by the kernel module to rewrite the corresponding field storing the acknowledgment number in the local protocol control block to the value of the received acknowledgment number. Simultaneously, the left boundary variable of the receive window in the local protocol control block is also adjusted synchronously. This left boundary variable indicates the starting position of the data stream in the receive buffer; setting it to the value of the received acknowledgment number indicates that all data before the received acknowledgment number has been acknowledged and does not need to be retransmitted. If the comparison result shows that the received acknowledgment number is less than or equal to the local maximum acknowledgment number, the acknowledgment progress of the local protocol stack is actually faster than or equal to the state in the snapshot, and the processing in step S454 is executed.

[0115] Step S454: If the received acknowledgment number is less than or equal to the local maximum acknowledgment number, keep the acknowledgment status of the local protocol stack unchanged, and generate an acknowledgment number alignment flag. Record this alignment event for subsequent log auditing.

[0116] After confirming that the received acknowledgment number is not greater than the local maximum acknowledgment number, the service agent process decides not to modify variables related to the acknowledgment progress in the local protocol stack to avoid introducing unnecessary state rollback. Instead, the service agent process generates an acknowledgment number alignment marker record in the local log system. This record is a structured log entry containing the current system timestamp, stream identity marker, the received acknowledgment number value in the snapshot, the local maximum acknowledgment number value, and an event type code indicating an acknowledgment number alignment event. This log entry is written to the system audit log file or a circular log buffer for subsequent querying by maintenance personnel or automated diagnostic systems to trace the processing history of the acknowledgment number status during this migration.

[0117] Step S455: Compare the sent sequence number extracted from the snapshot with the sequence number of the first byte in the local sent queue, calculate the difference between the two, convert the difference into a base offset of the local sent sequence number, and apply the offset to the sequence numbers of all messages in the local sent queue.

[0118] The local pending-send queue is a queue structure that stores unsent or retransmitted data packets in the sending direction of the adjacent edge computing node's protocol stack. Each packet has an assigned sending sequence number, which indicates the packet's byte-level position in the entire transport stream. The service agent process first reads the packet at the beginning of the local pending-send queue and extracts its sending sequence number value. Then, it subtracts the header packet sequence number value from the sending sequence number value extracted from the snapshot to obtain a signed integer difference, i.e., the base offset. This difference represents the positional difference between the current serving edge computing node and the local protocol stack in the sending sequence space. For example, if the snapshot sending sequence number is 5,000 and the local header packet sequence number is 1,000, then the base offset is 4,000. The service agent process then iterates through all packets in the local pending-send queue, adding this base offset to the sequence number field of each packet, completing the overall translation of the sequence number space so that the local sending sequence number is consistent with the source node.

[0119] Step S456: After completing the sequence number and acknowledgment number correction operations, rewrite the corrected protocol control block state into the network protocol stack of the adjacent edge computing node, and release the memory occupied by the temporary network connection state snapshot.

[0120] The protocol control block state rewrite operation is completed by calling the batch state synchronization function provided by the kernel module. This function accepts the complete image memory address and length of the corrected protocol control block as parameters, and uses a direct memory copy method to overwrite the corrected state into the memory region of the actual protocol control block corresponding to the socket pre-allocated in the kernel for the stream identity tag. The write operation must be performed atomically under the protection of kernel synchronization primitives, such as by holding spinlocks or mutexes to prevent other parts of the protocol stack from accessing the protocol control block at the same time. After the write is complete, the service agent process calls the memory release function to release the temporary areas outside the region where the actual protocol control block is located in the isolated memory region occupied by the process memory image, network connection state snapshot, and session key material pulled in step S430, including the original copy of the network connection state snapshot, in order to reclaim system memory resources.

[0121] Step S460: After completing the data retrieval, writing, and correction operations, all adjacent edge computing nodes mark the service context associated with the flow identity tag within their own nodes as pending activation and reply to the SDN controller with a status synchronization response.

[0122] After the service agent process completes memory release in step S456, it changes the status field of the entry corresponding to the flow identity tag in the service status table maintained by this node from "synchronizing" to "awaiting activation." This status change operation is completed through an atomic write or a locked write operation to ensure the visibility of the status in a multi-threaded environment. Subsequently, the service agent process constructs a status synchronization completion response message, the message body of which includes the flow identity tag, the local node identifier, a status code indicating success, and a completion timestamp. This response message is sent back to the service status synchronization module of the SDN controller through a secure control channel. The service status synchronization module collects the status synchronization completion responses from all adjacent edge computing nodes. When it receives a success status code from every node corresponding to the identifier of each adjacent edge computing node in the service location candidate set, the service status synchronization module internally marks this flow status synchronization task as globally completed, awaiting the triggering of a switch event.

[0123] Step S500: When a user equipment switches from the current access point to any adjacent access point, the second switch connected to the new access point automatically matches and wakes up a corresponding dormant shadow flow table entry based on the flow identity tag. The priority of the woken shadow flow table entry is instantly increased and overwrites the primary flow table entry. At the same time, a service context activation signal pointing to the corresponding adjacent edge computing node is triggered, completing the uninterrupted takeover of the service flow.

[0124] In one implementation, step S500 may specifically include the following steps S510 to S560: Step S510: When the second switch receives the first packet whose source address is the device identifier of the user equipment and whose destination address is any address, it parses the flow identity tag field from the packet header and sends the value of the flow identity tag field into its internal flow table lookup pipeline.

[0125] A device identifier is a unique identifier for a user equipment (UE) within a network, such as the Media Access Control (MAC) address of its network interface card. When a UE completes a wireless handover from its current access point to a neighboring access point, its network protocol stack may immediately send a message, such as an Address Resolution Protocol (ARP) request or a retransmitted data packet. After this message enters the receiving port of the second switch, the switch's message parser first parses the message header. Following the Ethernet frame format, the parser extracts the source MAC address field from the frame header and compares it with the UE's device identifier to confirm that the message indeed originates from that UE. Simultaneously, the parser extracts the necessary fields for the flow identity tag from the corresponding offsets in the network layer header and transport layer header. Using the same hash algorithm as the SDN controller in step S100, it calculates a flow identity tag value in real-time within the switch's internal hash calculation unit. This flow identity tag value is encapsulated in the switch's internal message descriptor structure and, along with the original message, is sent to the flow table lookup pipeline.

[0126] Step S520: The flow table lookup pipeline performs parallel matching on all flow table entries of the second switch. Since all dormant shadow flow table entries are still participating in the lookup and matching but are marked as dormant, the pipeline pauses the forwarding processing of the packet after hitting a matching dormant flow table entry, and sends the packet and the index of the matching flow table entry to the wake-up processing unit.

[0127] The flow table lookup pipeline is a multi-stage or parallel matching engine within the switch hardware, typically composed of a tri-state content-addressable memory and a static random access memory. When a packet carrying a flow identity tag enters the pipeline, the matching engine simultaneously performs tri-state content-addressable comparisons in the matching fields of all installed flow table entries. The shadow flow table entries pre-installed in step S300, because their matching fields are completely identical to the primary flow table entries (i.e., exact matches of the flow identity tag), will still be hit during this stage of the matching process, even if these shadow flow table entries are in a dormant state. After determining that a flow table entry has been hit, the matching engine reads the status flag field of that flow table entry. If the status flag is detected as a dormant state code, the matching engine does not directly execute the action instruction for that flow table entry, but instead triggers an exception handling process. The exception handling process suspends the subsequent forwarding pipeline stages of the packet, temporarily stores the packet in an internal packet buffer, and encapsulates the physical index number of the hit flow table entry in the hardware flow table into a wake-up request signal, which is then sent to the switch's wake-up processing unit. The wake-up processing unit is a programmable hardware logic module or embedded microprocessor subsystem located on the switch control plane, specifically responsible for handling the activation transactions of dormant flow table entries.

[0128] Step S530: The wake-up processing unit accesses the extended attribute area of ​​the shadow flow table entry according to the flow table entry index, reads the wake-up token value stored therein, and at the same time reads the authorization token preset by the second switch from the local security module of the second switch, and compares and verifies the wake-up token value with the authorization token.

[0129] In one implementation, step S530 may specifically include the following steps S531 to S536: Step S531: The wake-up processing unit calculates the physical address of the extended attribute area from the hardware storage unit of the shadow flow table entry by adding a fixed offset to the flow table entry index, initiates a hardware register read operation to the physical address, and obtains the complete wake-up token value stored in the extended attribute area.

[0130] The hardware storage unit is the physical storage device inside the switch used to store all fields of flow table entries. It is typically an associative data memory, such as high-speed static random access memory or tri-state content-addressable memory. Each flow table entry occupies a fixed-length slot in this storage unit. The starting base address of the slot is calculated by multiplying the flow table entry index by the slot size. The offset of the extended attribute area within each flow table entry slot is a constant value determined during the switch hardware design phase. The wake-up processing unit contains an address calculation unit. This unit shifts the flow table entry index left or multiplies it by a fixed logarithm of the slot size to obtain the slot base address. Then, it adds the slot base address to the fixed offset of the extended attribute area to obtain the precise physical address of the wake-up token field in the extended attribute area. Subsequently, the wake-up processing unit initiates a register read transaction to this physical address via the internal bus. The hardware storage controller responds to this transaction by returning the first few consecutive bytes starting at that address—the complete wake-up token value—to the wake-up processing unit and latching it into its internal register.

[0131] Step S532: The wake-up processing unit synchronously sends a token request to the local security module of the second switch. The local security module is an independent hardware root of trust that stores the authorization token injected by the SDN controller when the switch starts up. This authorization token is not related to the flow identity tag but is only bound to the switch device.

[0132] The local security module is a separate hardware security chip or a security logic block within a field-programmable gate array (FPGA) on the second switch's motherboard. Internally, it contains tamper-proof non-volatile memory and a dedicated cryptographic engine. After the switch starts up and establishes a secure connection with the SDN controller, the SDN controller issues a globally unique or system-unique authorization token via an encrypted management channel and securely programs it into the local security module's non-volatile memory. This authorization token is a random byte sequence with sufficient entropy to prove that the subsequent wake-up operation was initiated by the authorized switch holding the token. The wake-up processing unit sends a token read command frame to the local security module via a dedicated internal bus interface, such as an inter-integrated circuit bus or a serial peripheral interface. Upon receiving the command frame, the local security module does not perform additional verification of the requester's identity. Instead, it directly reads the binary sequence of the authorization token from its internal secure memory via direct memory access, encapsulates it in a response frame, and sends it back to the wake-up processing unit via a dedicated data channel.

[0133] Step S533: After receiving a token request, the local security module does not verify the identity of the requester, but directly sends the binary sequence of the authorization token in its internal secure storage area to the wake-up processing unit through a dedicated data channel. After sending, it automatically locks the secure storage area until the next request.

[0134] The locking mechanism of the secure storage area is controlled by the access control state machine within the local security module. After sending a response frame, the state machine immediately disables the read enable signal for the secure storage area and resets the internal address counter, preventing the contents of the secure storage area from being stolen in bulk through continuous read operations. The state machine only unlocks the read enable when it receives the start condition for the next new token read command frame. This design ensures the security of the authorization token and prevents accidental token leakage due to malicious processes or hardware failures.

[0135] Step S534: After receiving the binary sequence of the authorization token, the wake-up processing unit starts a bit-by-bit hardware comparator, performs an XOR operation on each bit of the wake-up token value and the corresponding bit of the authorization token, and performs a logical AND operation on all the XOR results to obtain a single-bit verification result.

[0136] The bit-by-bit hardware comparator is a combinational logic circuit within the wake-up processing unit, consisting of multiple XOR gates and a cascaded multi-input AND gate. An XOR gate is a digital logic gate that outputs a logic high level when two input bits are the same, and a logic low level when they are different. The comparator connects the wake-up token value byte sequence obtained in step S531 and the authorization token byte sequence obtained in step S532, bit-aligned, to the inputs of several sets of XOR gates. For example, if both tokens are 256 bits long, the comparator contains 256 XOR gates. The outputs of all XOR gates are connected to the inputs of a multi-level AND tree, whose final output is a single-bit signal. If every bit of the wake-up token value and the authorization token value is exactly the same, all XOR gate outputs are high, and the AND tree ultimately outputs a high level, indicating successful verification. If any bit is inconsistent, at least one XOR gate outputs a low level, causing the AND tree to output a low level, indicating verification failure.

[0137] Step S535: If the single-bit verification result is logically true, the verification is deemed successful. The processing unit is woken up to unlock the subsequent state modification process, and the successful verification record is written to the security audit log of the switch. The log includes the current system clock count value and flow table entry index.

[0138] In digital circuits, a logical truth is represented by a high-level signal. When the finite state machine inside the wake-up processing unit samples a high-level verification result, it transitions from the waiting verification state to the wake-up execution state, opening the gating signal for subsequent state modification procedures. Simultaneously, the state machine triggers a security audit log recording operation. The security audit log is an append-only log area in the switch's internal non-volatile memory. The state machine constructs a log entry containing the event type code "successful wake-up verification," the current system clock counter value, and the flow table entry index passed in step S520. This entry is then sequentially written to the end of the security audit log by the storage controller, updating the log write pointer.

[0139] Step S536: If the single-bit verification result is logically false, the verification is determined to be false. The wake-up processing unit immediately locks the shadow flow table entry, forces its state to permanently sleep, and sends a security alarm message through the southbound interface of the SDN controller. The message includes the index of the locked flow table entry and the current system clock count value.

[0140] A logical false signal is represented by a low-level signal. Upon sampling a low level, the state machine immediately enters a security exception handling state. In this state, the state machine first rewrites the status code in the status control field of the shadow flow table entry corresponding to the flow table entry index to a special code value representing permanent sleep, such as an all-one bit pattern. The difference between permanent sleep and normal sleep is that the state machine will no longer respond to any wake-up requests for this flow table entry. Subsequently, the state machine constructs a security alarm message, which follows the asynchronous notification message format of the SDN southbound interface, with the message type code marked as a security alarm, and the message body containing the locked flow table entry index and the current system clock count value. The state machine, through the switch's management agent process, encapsulates this security alarm message into an asynchronous event packet of the southbound interface and immediately reports it to the SDN controller.

[0141] Step S540: After verification, the wake-up processing unit directly modifies the hardware status register of the shadow flow table entry, rewriting the status code from a value representing sleep to a value representing activity. At the same time, the value of the priority field of the shadow flow table entry is changed from shadow priority to instantaneous highest priority, which is higher than all normal priorities.

[0142] The hardware status register is a physical trigger array that stores the status code of each flow table entry. The wake-up processing unit writes a transaction to a register, rewriting the value of the corresponding bit field of the shadow flow table entry in the status register from the sleep status code written in step S341 to the active status code, for example, changing the hexadecimal value 0x0F to 0xF0 or 0x01. In the same bus cycle or the immediately following bus cycle, the wake-up processing unit locates the hardware register containing the priority field of the shadow flow table entry and modifies the value of that field from the shadow priority value written in step S330, for example, ten, to a predefined instantaneous highest priority value. The instantaneous highest priority value is set to a value above all normal priority ranges. For example, if the normal priority range is zero to 25,000, the instantaneous highest priority value can be set to 65,535 or the maximum value allowed by the protocol, ensuring that the woken-up shadow flow table entry can immediately surpass any existing primary flow table entry and be preferentially matched during flow table lookup.

[0143] Step S550: The moment the priority modification takes effect, the pipeline of the second switch re-executes the flow table lookup for the previously paused packets. At this time, the packet hits the awakened flow table entry, and forwards the packet from the corresponding outgoing port according to the destination address specified by the action field. The direction of the outgoing port points to the corresponding adjacent edge computing node.

[0144] In one implementation, step S550 may specifically include the following steps S551 to S556: Step S551: After the pipeline of the second switch completes the priority modification of the flow table entry, it retrieves the first paused packet from the internal buffer and puts it back into the parsing level of the pipeline. The parsing level re-identifies the flow identity tag and sends it to the flow table lookup level.

[0145] The internal buffer is a high-speed packet buffer storage area embedded within the switch, typically implemented by multiple virtual output queues or a centralized shared buffer. After receiving a wake-up completion status signal, the pipeline scheduler sends a dequeue request to the buffer management unit, containing a pointer to the storage address of the paused packet in the buffer. The buffer management unit reads the complete packet data from static random access memory based on this pointer and injects it into the pipeline's parsing level via the data bus. The protocol parsing hardware in the parsing level re-parses the packet in exactly the same way as in step S510, extracting the original flow identity tag fields from each layer of the packet header, and the hash calculation unit recalculates the flow identity tag value. The calculation result is filled into a new internal packet descriptor. This descriptor enters the next level flow table lookup stage synchronously with the packet.

[0146] Step S552: At the flow table lookup level, the packet directly hits the flow table entry that has been awakened and has the highest priority. The action instruction set pointed to by the lookup result requires the destination address of the packet to be rewritten to the network address of the corresponding adjacent edge computing node, and the packet to be sent out from the physical port connected to the adjacent edge computing node.

[0147] The tri-state content-addressable memory in the flow table lookup stage performs a parallel lookup on all flow table entries, based on the flow identity tag value in the packet descriptor. Since the awakened shadow flow table entry now has the highest instantaneous priority and its matching field is an exact match of the flow identity tag, the lookup arbitrator selects this flow table entry as the final matching result. The lookup arbitrator reads the action instruction set corresponding to this flow table entry from the associated static random access memory. The content of the action instruction set is the action constructed and written in step S330: packet destination address rewriting. The pipeline's action execution stage executes this action, modifying the destination address field in the packet header. Simultaneously, the outgoing port mapping logic sets the outgoing port number to the physical port index connecting the corresponding adjacent edge computing node based on the internal metadata of the outgoing port bound in the flow table entry. The modified packet is sent to the sending queue of that outgoing port, waiting for the media access control layer to send the packet to the physical link.

[0148] Step S553: ​​During the same clock cycle in which the packet is sent to the forwarding queue to wait for the outgoing port to send, the control plane of the second switch generates an in-band telemetry trigger. The in-band telemetry trigger is encapsulated as a service activation signal packet. The destination address of the service activation signal packet is the same as the destination address of the packet, and its payload contains a wake-up token value and a service activation command code.

[0149] In-band telemetry triggering is a hardware mechanism in a switch pipeline that triggers the control plane to automatically generate a specific control or telemetry message while a data packet passes through the pipeline. In this implementation, this triggering is configured as a service activation signal message generation trigger. When the pipeline sends the user's first packet into the outgoing port send queue, a metadata signal associated with that packet is passed to the switch's control plane message generator. The control plane message generator is a programmable packet generation engine that quickly assembles a new service activation signal message based on the flow table entry index and packet destination address carried in the trigger signal. In the message header, the destination address field is copied to the user packet's destination address, i.e., the network address of the corresponding adjacent edge computing node. The message payload is filled by the message generator according to a predefined format, including a copy of the wake-up token value read in step S531, and an instruction code representing a service activation operation, such as a four-byte opcode 0xAC71A7E0. The payload may also contain a copy of the flow identity tag to help the receiving node quickly locate the service context to be activated. After the service activation signal message is assembled, it is given the same forwarding processing as user messages and is finally inserted into the same outgoing port transmission queue as user messages.

[0150] Step S554: The second switch inserts the service activation signal message into the sending queue of the same port with the highest priority, so that it is sent immediately after the first message, ensuring that the service activation signal message and the first message arrive at the adjacent edge computing node in a strict order on the physical link.

[0151] The scheduler of the sending queue supports a message priority mechanism. When the second switch's forwarding logic pushes the service activation signal message into the sending queue, it assigns it a flag indicating the highest priority within the queue, which is higher than the priority of ordinary data packets. During dequeueing, the scheduler prioritizes high-priority messages. Since the first user message has already been pushed into the sending queue in step S552, and the service activation signal message is pushed in the following clock cycle and assigned the highest priority, the scheduler will send the user message first, followed by the service activation signal message in the next available sending slot. This tightly coupled sending order ensures that the transmission gap between the two messages on the physical link is only the frame interval, guaranteeing that the service activation signal message will arrive within a very short time window after the user message arrives at the network interface card of the adjacent edge computing node, and that their order will not be reversed due to queuing by intermediate network devices.

[0152] Step S555: After receiving the service activation signal message, the network interface card of the adjacent edge computing node parses out the service activation command code and wake-up token value in the load, and immediately triggers the instantaneous flip of the local service context from the pending activation state to the active state. The flip process includes binding the socket in the service context to the physical interface and starting the main event loop of the application process.

[0153] The network interface card (NIC) adjacent to the edge computing node has packet payload parsing and fast channel distribution capabilities. When the NIC hardware recognizes a packet with a destination address of the local machine and a service activation command code in its payload, it directly submits the packet payload to the service proxy process through a pre-registered fast data path, bypassing the operating system's standard network protocol stack. The service proxy process parses the payload, extracts the service activation command code and wake-up token value, and locates the service context entry marked as pending activation in step S460 in the local service status table using the flow identity tag as an index. The service proxy process compares the wake-up token value with the expected token value stored in the entry; if they match, it performs an instantaneous flip operation. The flip operation consists of two atomic steps: First, a system call from the operating system kernel is invoked to bind the pre-allocated socket to the specified physical network interface, completing the association between the socket and the network interface. At this point, the socket can begin to receive and send data packets. Second, a start signal is sent to the application process associated with the service context, triggering the application process's main event loop to switch from a blocked waiting state to a running state, and begin reading and processing data packets from the socket's receive queue.

[0154] Step S556: After the main event loop of the application process starts, it begins to process the first packet taken from the network interface card receive queue. Since the network connection state correction in the service context has been completed in the early stage, the processing of this packet by the application process is completely connected with the processing of the node before the migration, and the upper layer application is unaware of this switching process.

[0155] The application process's main event loop is a continuously running loop structure that calls the operating system's event wait function in each iteration to listen for readable events on the socket. After socket binding is completed and the main event loop is started in step S555, the main event loop immediately enters its first iteration, calling the event wait function. Since the user packet sent immediately after the user packet in step S554 has now arrived at the network interface card and been placed into the socket's receive queue after processing by the network card and protocol stack, the event wait function immediately returns a readable event. The application process calls the socket read function to retrieve the data payload of the first user packet from the receive queue. Because the network connection state has been silently corrected in step S450, including the migration of sequence number and acknowledgment number spaces, the application process and protocol stack are in the correct state space for validating the packet sequence number, processing the data content, and calculating the sequence number of any subsequent response packets. The application process processes the packet according to its original business logic, generating corresponding application-layer behaviors. The processing result is completely consistent with the result that would have been produced if the packet had been processed on the original current service edge computing node. From the perspective of the upper-layer application, the entire access point switching process manifests as only an imperceptible micro-jitter in network latency, ensuring the continuity of business flow and achieving uninterrupted takeover.

[0156] Step S560: After completing the above operations, the wake-up processing unit generates a flow table entry wake-up event carrying a wake-up token and an activation completion timestamp, and asynchronously reports the flow table entry wake-up event to the SDN controller through the southbound interface of the SDN controller.

[0157] The Flow Table Entry Wake-up Event is an asynchronous event message type defined by the SDN Southbound Interface Protocol. It is used by the switch to proactively report critical state changes occurring in the data plane to the controller. After the finite state machine inside the wake-up processing unit successfully enqueues the service activation signal message in step S554, it confirms that the entire wake-up process has been successfully executed and then constructs a Flow Table Entry Wake-up Event message. The binary payload of this message includes: the event type code is Flow Table Entry Wake-up Event; the index of the wake-up flow table entry; the digest information of the wake-up token value, such as its hash value; and an activation completion timestamp field, which is taken from the count value of the switch's local high-precision hardware clock at the moment the priority modification takes effect in step S540. This message is reported to the SDN controller's flow table management core module in the form of an asynchronous notification through the switch's management agent process and the secure connection of the southbound interface. After receiving the event, the SDN controller updates the corresponding entry in its global flow state table, marking that the service node of the service flow has successfully switched to the corresponding adjacent edge computing node, completing the closed-loop confirmation of the entire switching process.

[0158] Figure 3A hardware entity diagram of a computer system provided as an embodiment of the present invention, such as... Figure 3 As shown, the hardware entity of the computer system 1000 includes a processor 1001 and a memory 1002, wherein the memory 1002 stores a computer program that can run on the processor 1001, and the processor 1001 executes the program to implement the steps in the method of any of the above embodiments.

[0159] The memory 1002 stores computer programs that can run on the processor. The memory 1002 is configured to store instructions and applications that can be executed by the processor 1001. It can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) of the processor 1001 and various modules in the computer system 1000. It can be implemented by flash memory or random access memory (RAM).

[0160] When processor 1001 executes a program, it implements the steps of the SDN-based edge computing node task resource scheduling method described above. Processor 1001 typically controls the overall operation of computer system 1000.

[0161] This invention provides a computer storage medium that stores one or more programs, which can be executed by one or more processors to implement the steps of the SDN-based edge computing node task resource scheduling method as described in any of the above embodiments.

[0162] It should be noted that the descriptions of the above storage medium and device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of the present invention, please refer to the descriptions of the method embodiments of the present invention for understanding. The processor described above can be at least one of an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a controller, a microcontroller, and a microprocessor. It is understood that the electronic device implementing the above processor function can also be other types, and the embodiments of the present invention do not specifically limit it.

[0163] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0164] The above description is merely an embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for scheduling task resources of an SDN-based edge computing node, characterized in that, include: The system receives the current access point identifier of the user equipment and the first packet of the service flow of the user equipment synchronized by the SDN controller, extracts the flow identity tag from the first packet of the service flow, and uses the current access point identifier and the flow identity tag as a flow tracing identifier pair. Based on the flow tracing identifier, query the pre-built access point-edge service mapping view, obtain the current service edge computing node identifier bound to the current access point identifier and the set of adjacent edge computing node identifiers bound to all adjacent access point identifiers that have an adjacency relationship with the current access point identifier, and generate a service location candidate set containing the current service location and alternative service locations; Send a flow table shadow construction instruction carrying the flow identity tag and the service location candidate set to the SDN controller, so that the SDN controller creates a primary flow table entry pointing to the current service edge computing node identifier for the flow identity tag at the first switch connected to the current access point, and creates a corresponding shadow flow table entry for each adjacent edge computing node identifier in the service location candidate set. Each shadow flow table entry has a lower priority than the primary flow table entry and is initially in a dormant state. After the first switch completes the installation of all shadow flow table entries, it sends a service status synchronization instruction carrying the flow identity tag to all edge computing nodes in the service location candidate set. The service status synchronization instruction instructs each edge computing node to synchronize the service context associated with the flow identity tag from the current service edge computing node according to the flow identity tag, and set the synchronized service context to the pending activation state. When the user equipment switches from the current access point to any of the adjacent access points, the second switch connected to the new access point automatically matches and wakes up a corresponding dormant shadow flow table entry based on the flow identity tag. The priority of the woken shadow flow table entry is instantly increased and overwrites the primary flow table entry. At the same time, a service context activation signal pointing to the corresponding adjacent edge computing node is triggered, completing the uninterrupted takeover of the service flow.

2. The method of claim 1, wherein, The process involves querying a pre-built access point-edge service mapping view based on the flow tracing identifier, obtaining the current service edge computing node identifier bound to the current access point identifier, and the set of adjacent edge computing node identifiers bound to all adjacent access point identifiers that are adjacent to the current access point identifier, generating a service location candidate set containing the current service location and alternative service locations, including: Parse the flow tracing identifier pair to separate the current access point identifier and the flow identity tag. Use the current access point identifier as the index key to query the locally cached access point-edge service mapping view from the SDN controller. The access point-edge service mapping view is organized with the access point identifier as the primary key and the associated set of edge computing node identifiers as the key. Read the edge computing node identifier directly associated with the current access point identifier from the access point-edge service mapping view, determine the edge computing node identifier as the current service edge computing node identifier, and obtain the service status description corresponding to the current service edge computing node identifier. The service status description includes the current load status and a list of running service instances. The topology adjacency extension table of the access point-edge service mapping view is queried. The topology adjacency extension table defines the adjacency association between each access point identifier and other access point identifiers with physical signal coverage overlap. Based on the adjacency association, all adjacent access point identifiers that have an adjacency relationship with the current access point identifier are retrieved from the topology adjacency extension table. Iterate through each of the retrieved adjacent access point identifiers, and then use that adjacent access point identifier as the index key to query the access point-edge service mapping view again to obtain the candidate edge computing node identifiers bound to each adjacent access point identifier. After deduplicating all candidate edge computing node identifiers, they are collected into the adjacent edge computing node identifier set. The current service edge computing node identifier is used as the central node, and each identifier in the set of adjacent edge computing node identifiers is used as a leaf node. Together with the flow identity tag, they are encapsulated into a service location candidate set data structure with the flow identity tag as the unique identifier. The service location candidate set data structure is stored in the global location cache of the SDN controller, and a ready notification carrying the memory address of the service location candidate set data structure is sent to the flow table shadow construction process.

3. The method of claim 2, wherein, The query retrieves the topology adjacency extension table of the access point-edge service mapping view. This table defines the adjacency associations between each access point identifier and other access point identifiers with overlapping physical signal coverage, including: Extract the embedded topology adjacency extension table from the access point-edge service mapping view. The topology adjacency extension table is stored in the form of an adjacency matrix with the access point identifier as the row index and the list of adjacent access point identifiers as the row data. Based on the current access point identifier, a binary search is performed in the row index of the topology adjacency extension table to locate the row record that completely matches the current access point identifier. If no matching row record is found, an empty set of adjacency access point identifiers is returned and the query process ends. Read the stored list of adjacent access point identifiers from the located row records, use the list of adjacent access point identifiers as the initial adjacency set, and at the same time create a temporary set to store the extended adjacency results; For each adjacent access point identifier in the initial adjacency set, check whether it has been marked as processed. If it has not been marked, add the adjacent access point identifier to the temporary set and mark it as processed. At the same time, check whether the row record of the adjacent access point identifier contains the adjacent adjacent access point identifier. If the row record of the currently processed adjacent access point identifier contains adjacent adjacent access point identifiers, then compare these adjacent adjacent access point identifiers with the initial adjacent set, append new identifiers that do not belong to the initial adjacent set to the temporary set, and repeat this expansion step until no new identifiers are appended. All access point identifiers in the temporary set are used as the final retrieved identifiers of all adjacent access points that are adjacent to the current access point identifier, and the retrieval results are written into the query result buffer.

4. The method of claim 2, wherein, The step of encapsulating the current service edge computing node identifier as the central node, each identifier in the set of adjacent edge computing node identifiers as a leaf node, together with the flow identity tag, into a service location candidate set data structure with the flow identity tag as the unique identifier includes: Allocate a contiguous storage area in memory to construct a service location candidate set data structure, and write the stream identity tag at a fixed offset at the beginning of the contiguous storage area as a globally unique retrieval key for the data structure. After the flow identity tag, a count value indicating the number of central nodes is written, where the count value is fixed at 1. Then, the current service edge computing node identifier is written into the central node identifier field, followed by the central node type identifier to indicate that the node is the current service provider. After the central node field is written, the leaf node count field is written, the value of which is the total number of elements in the adjacent edge computing node identifier set. Then, all the identifiers in the adjacent edge computing node identifier set are written sequentially into the consecutively arranged leaf node identifier field. After each leaf node identifier field, a status flag field is appended, and the initial value of all status flag fields is uniformly set to the first status value representing the standby state. At the same time, the status flag field after the central node identifier field is set to the second status value representing the active state. Obtain the current precise time from the SDN controller, convert the current precise time into a timestamp format, write it into the reserved creation timestamp field in the contiguous storage area, and increment the value of the reserved version number field by 1 before writing it to complete the version update; The starting address of the contiguous storage region is converted into a pointer, and together with the stream identity tag, it is encapsulated into a ready notification message, which is sent to the stream table shadow construction process through the inter-process communication channel, and the temporary variables outside the contiguous storage region are reclaimed.

5. The method of claim 1, wherein, The step of sending a flow table shadow construction instruction carrying the flow identity tag and the service location candidate set to the SDN controller enables the SDN controller to create a primary flow table entry pointing to the current service edge computing node identifier for the flow identity tag at the first switch connected to the current access point, and simultaneously create a corresponding shadow flow table entry for each adjacent edge computing node identifier in the service location candidate set, including: The SDN controller receives the flow table shadow construction instruction, parses out the flow identity tag and the service location candidate set, extracts the current service edge computing node identifier from the service location candidate set, obtains the destination network address of the node in the SDN data plane, and writes the destination network address into the main action instruction set; In the flow table construction memory area, a prototype of the primary flow table entry is created. The flow identity tag is written into the matching field of the primary flow table entry prototype in an exact matching manner. The primary action instruction set and the priority field representing the normal priority are written into the action field and attribute field of the primary flow table entry prototype. Traverse each adjacent edge computing node identifier in the service location candidate set, query the destination network address corresponding to each adjacent edge computing node identifier, construct a shadow flow table entry prototype for each destination network address, write the flow identity tag into the matching field of each shadow flow table entry prototype, but write the corresponding destination network address into its action field, and fill in a shadow priority value that is significantly lower than the normal priority into its priority field. Set an initial state flag for each shadow flow table entry prototype, set the initial state flag to a dormant state representing that the rule exists but does not participate in data plane matching, and append a zero-value hit counter to the statistics field of each shadow flow table entry prototype; The primary flow table entry prototype and all shadow flow table entry prototypes are encapsulated together into a flow table batch installation request, and the flow table batch installation request is sent to the first switch through the southbound interface of the SDN controller. The system receives a batch installation confirmation returned by the first switch. The batch installation confirmation corresponds to the installation result of each flow table entry prototype. After confirming that all installations are successful, the system sends an installation completion notification carrying the flow identity tag and all shadow flow table entry identifiers to the service status synchronization module.

6. The method of claim 5, wherein, The step of setting an initial state flag for each shadow flow table entry prototype, and setting the initial state flag to a dormant state representing the existence of a rule but its non-participation in data plane matching, includes: Access the shadow flow table entry state definition library maintained by the SDN controller, retrieve the predefined dormant state state code from the state definition library, the dormant state state code is mutually exclusive with the active state state code, and in the flow table entry matching pipeline, flow table entries in the dormant state will be automatically skipped by the hardware lookup engine. In the reserved state control field in the shadow flow table entry prototype, write the state code of the retrieved dormant state, and at the same time write a control bit to disable interruption in the reserved bit of the state control field to prevent the dormant flow table entry from generating an interrupt signal when it is accessed unexpectedly. After writing the state code of the dormant state, a wake-up token field is attached to the extended attribute area of ​​the shadow flow table entry prototype. A randomly generated wake-up token value is filled into this field. The wake-up token will serve as the only credential for switching from the dormant state to the active state. The wake-up token value and the identifier of the shadow flow table entry prototype are uploaded to the wake-up token mapping table of the SDN controller. The wake-up token mapping table stores the corresponding wake-up token value using a combination of flow identity tag and edge computing node identifier as an index. Before the SDN controller sends the shadow flow table entry prototype to the first switch, the integrity of the shadow flow table entry prototype is verified to ensure that the status control field and wake-up token field have been correctly written and are consistent with the records in the wake-up token mapping table. After the verification is successful, the configuration of the shadow flow table entry prototype is locked, and the locked shadow flow table entry prototype is submitted to the distribution queue to wait for batch installation. The step of encapsulating the primary flow table entry prototype and all shadow flow table entry prototypes together into a single flow table batch installation request, and sending the flow table batch installation request to the first switch through the southbound interface of the SDN controller, includes: Count the total number of flow table entries to be installed this time, add the number of primary flow table entry prototypes to the number of all shadow flow table entry prototypes to get the total number of installed entries, and write the total number of installed entries into the count field of the header of the flow table batch installation request. Calculate the total byte length required for the entire flow table batch installation request, request a contiguous memory block matching the total byte length from the southbound interface transmission buffer managed by the SDN controller, and if the request fails, enter a backoff wait and re-request after waiting; Following the order of primary flow table entry prototypes followed by shadow flow table entry prototypes, the complete binary representation of each flow table entry prototype is copied sequentially to the allocated contiguous memory block, with predefined delimiters separating the binary representations of each flow table entry prototype. Append a batch operation type code to the end of the contiguous memory block. The batch operation type code instructs the first switch to atomically write all flow table entries in this request to its flow table hardware storage, ensuring that either all writes are successful or all are rolled back. The batch write function of the southbound interface is called, and the starting address and total byte length of the contiguous memory block are passed in as parameters. The data is pushed to the management agent process of the first switch through the flow rule batch installation protocol of the southbound interface. Start a timeout retransmission timer and wait for the first switch to respond to the batch installation request. If a batch installation confirmation is received before the timer expires, the installation status of each item in the confirmation content is parsed. If the timeout occurs, the overall retransmission process is triggered.

7. The method of claim 1, wherein, Sending a service status synchronization instruction carrying the flow identity tag to all edge computing nodes in the service location candidate set, wherein the service status synchronization instruction instructs each edge computing node to synchronize the service context associated with the flow identity tag from the current service edge computing node according to the flow identity tag, includes: Using the current service edge computing node identifier in the service location candidate set as the context data source, query the service context directory of the node, extract the storage location offset and data length of the process memory image, network connection state snapshot and session key material associated with the flow identity tag, and form a context data block list; For each adjacent edge computing node identifier in the service location candidate set, an independent data retrieval task is generated. The data retrieval task includes the network address of the context data source, the list of context data blocks, and a target node write address. All generated data retrieval tasks are sent one by one to the corresponding adjacent edge computing nodes. Each data retrieval task instructs the receiving node to actively initiate a one-sided read operation based on remote direct memory access to the current service edge computing node, and retrieve all data blocks listed in the context data block list in a zero-copy manner. Within each adjacent edge computing node, the process memory image, network connection state snapshot, and session key material pulled from the current serving edge computing node are written into an isolated memory area pre-allocated for the stream identity tag, and the written data blocks are subjected to consistency verification. After the consistency check passes, each adjacent edge computing node silently corrects the network connection state it pulls based on the transmission control protocol sequence number and acknowledgment number in the network connection state snapshot, so that the network connection state is smoothly migrated to the protocol stack of this node. After completing the data retrieval, writing, and correction operations, each of the adjacent edge computing nodes marks the service context associated with the flow identity tag within its own node as pending activation and replies to the SDN controller with a status synchronization response.

8. The method of claim 7, wherein, Each data fetch task instructs the receiving node to proactively initiate a one-sided read operation based on remote direct memory access to the current service edge computing node, fetching all data blocks listed in the context data block list in a zero-copy manner, including: The receiving node parses the data retrieval task, obtains the network address of the current service edge computing node and the context data block list, and reads a data block descriptor sequentially from the context data block list. The data block descriptor contains a remote memory address, a local memory address and a data length. The network interface controller of the receiving node assembles a remote direct memory access read request message based on the remote memory address and the network address of the current service edge computing node, and sends the message directly to the network interface controller of the current service edge computing node through a priority queue. The entire process does not go through the operating system kernel network stack of the receiving node. After receiving the remote direct memory access read request message, the network interface controller of the current service edge computing node parses out the remote memory address, reads the corresponding data directly from the local physical memory, assembles it into a remote direct memory access read response message, carries the data length and the actual data load, and sends it back to the receiving node unilaterally. After receiving the read response message, the network interface controller of the receiving node writes the data payload directly to the memory location corresponding to the address through the direct memory access engine according to the local memory address carried in the message. After the writing is completed, the completion counter is incremented by one. The control process of the receiving node polls the completion counter. When the value of the completion counter is equal to the total number of data block descriptors in the context data block list, it is determined that all data blocks have been successfully fetched, and the data block consistency verification process is then triggered. If a remote direct memory access read request times out or returns an error during the retrieval process, the receiving node initiates a retransmission request for the data block descriptor and sends the retransmission request to the current service edge computing node until the data block is successfully retrieved or the preset maximum number of retransmissions is reached.

9. A computer system comprising a memory and a processor, said memory storing a computer program operable on the processor, characterised in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 8.

Images