Distributed core network cooperation system and method based on dynamic perception and intelligent decision

Abstract

The invention belongs to the technical field of wireless communication, and particularly relates to a distributed core network cooperation system and method based on dynamic perception and intelligent decision. The system comprises four layers: a terminal access layer used for receiving connection requests from various terminal devices; the dynamic discovery layer consists of different core network nodes, and each core network node is provided with a lightweight probe LSP (Label Switched Path) and is used for monitoring and acquiring the state of each node and periodically broadcasting the state information of the node to a multicast group through UDP (User Datagram Protocol) multicast; the intelligent decision-making layer is used for receiving the real-time node state and topology information from the dynamic discovery layer and the service SLA demand from the service layer, operating a dynamic weight decision-making engine, deciding an optimal node, and issuing a routing instruction to the terminal access layer or a corresponding node; and the data synchronization layer is used for synchronizing related state data from an original node to a new node when the decision relates to node switching or state transition.

Description

Technical Field

[0001] This invention belongs to the field of wireless communication technology, specifically relating to a distributed core network collaborative system and method based on dynamic sensing and intelligent decision-making. Background Technology

[0002] With the development of 5G-A and 6G technologies, the core network faces three major technical challenges: 1. Massive connectivity pressure: The Industrial Internet of Things (IIoT) needs to support millions of devices connected per square kilometer; 2. Extreme reliability requirements: uRLLC scenarios such as vehicle-to-everything (V2X) and remote surgery require extremely high availability; 3. Dynamic topology environment: The number of edge computing nodes grows exponentially, and the rate of change of network topology accelerates accordingly.

[0003] Traditional centralized core networks cannot meet demand due to single-point bottlenecks, such as central node failures leading to regional service interruptions and high latency fluctuations in business requests in centralized architectures.

[0004] Currently, the mainstream solutions in the industry use a distributed architecture to mitigate the risks of centralization, but there are some limitations, such as reliance on pre-configured static nodes; manual intervention is required to add / delete nodes, which is time-consuming; node failure monitoring has high latency; and data synchronization uses full replication, which consumes too much core link bandwidth.

[0005] Current distributed systems suffer from significant bottlenecks in node management, routing, and data synchronization. First, node discovery mechanisms are severely outdated, still relying on manual static configuration or periodic scanning (e.g., hourly polling). This results in high latency when new nodes join or failed nodes go offline, failing to detect topology changes in real time (e.g., traffic is still incorrectly routed to an edge node after it fails). Second, routing strategies are too rigid, relying solely on preset static weights (e.g., geographical distance or fixed cost coefficients) and ignoring real-time dynamic indicators (e.g., nodes with CPU utilization exceeding 80% are still assigned new tasks, or high-packet-loss links are not avoided). Finally, data synchronization mechanisms are inefficient, employing full backup modes (e.g., daily full database copying). This consumes excessive bandwidth, causing severe network congestion, especially during cross-regional transmissions, leading to increased latency for business requests during synchronization. These shortcomings collectively result in increased system response latency, unbalanced resource utilization, and higher operational costs. Summary of the Invention

[0006] In view of this, the present invention aims to achieve second-level dynamic node discovery and state-aware node selection, and provides a distributed core network collaborative system and method based on dynamic perception and intelligent decision-making.

[0007] The technical solution for implementing the present invention is as follows: In a first aspect, the present invention provides a distributed core network collaborative system based on dynamic perception and intelligent decision-making, comprising: a terminal access layer, a dynamic discovery layer, an intelligent decision-making layer, and a data synchronization layer; wherein, The terminal access layer is used to receive connection requests from various terminal devices. The dynamic discovery layer consists of different core network nodes, and each core network node deploys a lightweight probe LSP to monitor and collect the status of each node. It periodically broadcasts the status information of its own node to the multicast group via UDP multicast, listens for LMDP messages from other nodes in the multicast group, and maintains a real-time, in-memory neighbor node topology table. The intelligent decision layer is used to receive real-time node status and topology information from the dynamic discovery layer, as well as business SLA requirements from the business layer, run the dynamic weight decision engine, determine the optimal node, and send routing instructions to the terminal access layer or the corresponding node. The data synchronization layer is responsible for synchronizing relevant status data from the original node to the new node when the decision involves node switching or state migration, ensuring business continuity and synchronizing status data between nodes.

[0008] Optionally, the dynamic discovery layer of this invention monitors and collects the status of each node's hardware layer, operating system layer, network stack layer, and service layer; the message format for broadcasting its own status includes: version|node ID|timestamp|load weight|link quality|geographical location|.

[0009] Optionally, the link quality described in this invention is a comprehensive score calculated based on the most recently detected RTT, jitter, and packet loss rate. score=100×(1-loss)×(1-min(1,jitter / 10))×(1- min(1,(rtt-10) / 100)) Where loss represents packet loss rate, jitter represents jitter, and RTT represents packet loss rate.

[0010] Optionally, the intelligent node of the present invention runs a dynamic weight decision engine to determine the optimal node. The process is as follows: Based on the candidate node list and business SLA requirements, calculate the priority score of all eligible candidate nodes and select the one with the highest score as the optimal target node; at the same time, generate a queue of backup nodes in descending order of score for quick switching.

[0011] Optionally, the priority calculation formula of the present invention is as follows:

[0012] Where α, β, and γ are the set weights, Load comes from the load weight in the message; LinkQuality comes from the link quality score in the message; and Distance is calculated based on the geographical location and request source location in the message.

[0013] Optionally, the weights are dynamically adjusted according to the business type as described in this invention: When the service type is eMBB (high throughput): α=0.3, β=0.7, γ=0.0; When the service type is uRLLC (low latency, high reliability): α = 0.4, β = 0.5, γ = 0.1; When the service type is mMTC (massive machine-type communications): α=0.6, β=0.3, γ=0.1; In other cases, DEFAULT: α=0.4, β=0.5, γ=0.1.

[0014] Optionally, the intelligent decision-making layer of the present invention further operates a real-time avoidance mechanism, wherein the real-time avoidance mechanism is as follows: the decision engine will exclude nodes marked as FAULT / SUSPECT, nodes whose load exceeds the dynamic threshold, and nodes whose link quality is lower than the minimum requirement in real time; wherein, SUSPECT nodes are nodes that have not been detected with a heartbeat for N consecutive cycles, and FAULT nodes are nodes that have not been detected with a heartbeat for N+1 consecutive cycles.

[0015] Optionally, the data synchronization layer of the present invention performs dual-channel data synchronization, specifically as follows: Main channel: Used for efficient state synchronization triggered periodically or by events, transmitting changed data blocks, and using a sliding window comparison algorithm to identify differences; Auxiliary channel: Used to continuously record all state change operations.

[0016] Optionally, each log entry for state change described in this invention includes: operation type, data key, value before operation, value / parameter after operation, timestamp, and transaction ID.

[0017] Secondly, this invention provides a distributed core network collaborative method based on dynamic perception and intelligent decision-making, the specific process of which is as follows: The dynamic discovery layer continuously monitors the status of all nodes and pushes the real-time topology and node health status to the intelligent decision-making layer. The intelligent decision-making layer determines the optimal node based on the real-time node status and SLA requirements, and sends routing instructions to the terminal access layer or the corresponding node. If the decision involves node switching or state migration, the data synchronization layer is responsible for synchronizing the relevant state data from the original node to the new node to ensure business continuity.

[0018] Beneficial effects: This invention addresses the problem of rigid routing strategies by constructing an intelligent node selection algorithm based on multi-dimensional real-time indicators (load, link quality, distance, and service type) to dynamically avoid overloaded nodes and poor-quality links, thereby reducing the task allocation error rate. This invention addresses the problem of inefficient data synchronization by designing an efficient incremental synchronization mechanism that reduces the amount of synchronized data, minimizes the impact of the synchronization process on business bandwidth, and ensures strong consistency through a dual-channel design. Attached Figure Description

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

[0020] Figure 1 This is a system architecture diagram. Detailed Implementation

[0021] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0022] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0023] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0024] Full name / explanation of the term IIoT (Industrial Internet of Things) V2X (Vehicle to Everything) uRLLC (Ultra-Reliable Low-Latency Communication) eMBB (Enhanced Mobile Broadband) mMTC (Massive Machine Type Communication) LSP Lightweight State Probe LMDP (Lightweight Multicast Discovery Protocol) DB Change Data Block (Delta Block) Service Level Agreement (SLA) OpLog (Operation Log) like Figure 1 As shown in the figure, this application provides a distributed core network collaborative system based on dynamic perception and intelligent decision-making. The system includes four layers: Terminal access layer: responsible for receiving connection requests from various terminal devices such as industrial sensors, vehicle networking OBUs, and medical equipment; Dynamic discovery layer: Composed of different core network nodes, each core network node deploys a lightweight state probe (LSP). The LSP is responsible for: (1) Layered status acquisition: Status monitoring and acquisition of hardware layer, operating system layer, network stack layer and service layer; (2) Status broadcast: Using a custom lightweight multicast discovery protocol (LMDP), the node’s status information is broadcast periodically (e.g., every 200ms) to the multicast group via UDP multicast.

[0025] (3) Topology maintenance: Monitor LMDP messages from other nodes in the multicast group and maintain a real-time, in-memory neighbor topology table. When a new node is detected joining (ADVERTISE message) or a node fails (loss of N consecutive heartbeats), a topology update event is immediately triggered and a TOPOLOGY_UPDATE message is broadcast.

[0026] Intelligent Decision Layer: This layer receives real-time node status and topology information from the dynamic discovery layer, as well as business SLA requirements (such as latency requirements, reliability levels, and bandwidth requirements) from the business layer. This layer runs a dynamic weighted decision engine, calculating priority scores for candidate nodes based on preset and dynamically adjusted weight models, and outputting the optimal target node ID and its backup node list. The decision results are used to guide session establishment, user plane path selection, and service instance scheduling.

[0027] Data synchronization layer: Responsible for efficiently and reliably synchronizing state data (such as user session context and policy rules) between nodes (e.g., primary / backup nodes, collaborative processing nodes). Employs a dual-channel mechanism. (1) Incremental synchronization channel (main channel): Based on the sliding window difference comparison algorithm, it only identifies and transmits changed data blocks (Delta Block, DB) and uses efficient compression algorithms (such as LZ4 / Zstandard).

[0028] (2) Transaction log synchronization channel (secondary channel): Transmits operation logs (Redo Log), used for data repair and eventual consistency guarantee when incremental synchronization is abnormal or strong consistency is required.

[0029] The relationships between the four layers are as follows: The terminal initiates a request → The terminal access layer receives and transmits the service request and SLA requirements to the intelligent decision-making layer.

[0030] The dynamic discovery layer continuously monitors the status of all nodes and pushes the real-time topology and node health status to the intelligent decision-making layer.

[0031] The intelligent decision-making layer determines the optimal node based on the real-time node status and SLA requirements, and sends routing instructions to the terminal access layer or the corresponding node.

[0032] If the decision involves node switching or state migration, the data synchronization layer is responsible for synchronizing the relevant state data from the original node to the new node to ensure business continuity.

[0033] Throughout the process, the dynamic discovery layer senses changes in nodes in real time (such as faults or overloads), triggers the intelligent decision-making layer to make new decisions, and may also trigger the data synchronization layer to synchronize its state.

[0034] Furthermore, in this embodiment of the application, the dynamic discovery layer deploys lightweight probes on each core network node, and the discovery process is as follows: I. Node Status Acquisition and Broadcasting: Layered Perception Strategy (1) Hardware layer awareness A. The probe reads CPU utilization, core load, and temperature via the / proc / cpuinfo and sysfs interfaces; B. Obtain GPU utilization and video memory information via GPUDirect or NVML; C. Use ethtool and netstat -i to obtain network interface throughput and packet error / loss counts.

[0035] (2) Operating system layer awareness A. Monitor interrupt frequency via / proc / interrupts and / proc / stat; B. Use top / ps to obtain CPU / memory usage of key processes; use free / vmstat to monitor memory usage and swap activity. C. Monitor disk I / O using iostat.

[0036] (3) Network stack awareness A. Monitor TCP / UDP connection counts and status using ss / netstat; B. Obtain interface-level packet loss / error rate using ifconfig / ip -s link; estimate link RTT, jitter, and packet loss rate through active probing or passive packet capture analysis (such as using libpcap); C. Monitor the usage of the kernel protocol stack buffer.

[0037] (4) Business layer perception Monitor core network protocol processing: NGAP signaling processing rate / success rate, PFCP session establishment / modification / deletion latency and success rate, HTTP / 2 SBI interface response code distribution, user plane packet forwarding rate / latency / packet loss rate; monitor the health status (heartbeat) of core network function instances and resource pool (such as CPU / memory / session quota) utilization alarms.

[0038] The dynamic discovery layer monitors and broadcasts its own status via a customized UDP multicast protocol by deploying lightweight probes at each core network node. Message format: Version|Node ID|Timestamp|Load Weight|Link Quality|Geographic Location|.

[0039] Load weight: A normalized load value calculated by taking into account factors such as CPU, memory, and number of sessions.

[0040] Link quality: A comprehensive score calculated based on the most recently detected RTT, jitter, and packet loss rate (e.g., score=100). (1-loss)×(1 - min(1, jitter / 10))×(1 - min(1, (rtt-10) / 100)), assuming ideal RTT=10ms).

[0041] Geographic location: Used for distance calculation.

[0042] II. Dynamic Topology Maintenance Step 1: Node registration and deployment When a new node starts up, it sends an ADVERTISE message to a multicast group. The neighboring node replies with an ACK message and establishes a local topology table.

[0043] Step 2: Heart rate monitoring The probe sends a HEARTBEAT message every 200ms; Heartbeat timeout determination: If node A does not receive a HEARTBEAT from node B within 3 consecutive heartbeat cycles (i.e., 3 * 200ms = 600ms), node B is marked as SUSPECT; if it still does not receive one after another cycle (200ms), it is confirmed as FAULT. Total fault detection delay target <800ms.

[0044] Step 3: Exception Handling Topology update propagation: Upon detecting a FAULT or receiving an ADVERTISE, a node immediately generates a TOPOLOGY_UPDATE message and broadcasts it. This message contains the latest list of valid node IDs for the entire network / local area and their basic state summary. Receiving nodes atomically update their local topology tables.

[0045] Furthermore, the decision-making process executed by the intelligent decision-making layer in this embodiment is as follows: Input: Candidate node list + business SLA requirements (e.g., uRLLC business requires latency <5ms); Output: Calculate the priority score of all eligible candidate nodes and select the one with the highest score as the optimal target node. Simultaneously, generate a queue of spare nodes (configurable length, e.g., 3-5 nodes) arranged in descending order of score for quick switching.

[0046] Priority calculation formula:

[0047] Where α=0.4, β=0.5, γ=0.1, the weights can be dynamically adjusted by the decision engine according to the SLA type of the current business flow being processed, forming a business-aware decision model. Load comes from the load weight in the message; LinkQuality comes from the link quality score in the message; Distance is calculated based on the geographical location and the location of the request source (or the location of the target area) in the message.

[0048] The weights are dynamically adjusted based on the business type: IF Service Type = eMBB (High Throughput): α=0.3, β=0.7, γ=0.0 / / Prioritizes link quality (bandwidth), downplays load and distance. IF Service Type = uRLLC (Low Latency High Reliability): α = 0.4, β = 0.5, γ = 0.1 / / Balance load and link quality, appropriately considering distance. IF Service Type = mMTC (massive machine-type communications): α=0.6, β=0.3, γ=0.1 / / Prioritizes load balancing to avoid node overload. DEFAULT: α=0.4, β=0.5, γ=0.1 / / General business Real-time avoidance mechanism: The decision engine will exclude nodes marked as FAULT / SUSPECT, nodes whose load exceeds dynamic thresholds (e.g., eMBB: 90%, uRLLC: 70%), and nodes whose link quality is lower than the minimum requirement (e.g., uRLLC: link quality > 80) in real time.

[0049] Furthermore, the dual-channel collaborative process executed by the data synchronization layer in this embodiment is as follows: Main channel (incremental synchronization): Used for efficient state synchronization periodically (e.g., every second) or event-triggered (e.g., critical state changes), and is the default channel used.

[0050] Secondary channel (transaction log synchronization): Continuously records all state change operations (OpLog). Each log entry contains [Operation type (CRUD)] [Data key] [Value before operation (optional)] [Value after operation / parameter] [Time stamp] [Transaction ID].

[0051] The incremental synchronization channel only transmits changed data blocks (DB, Delta Block) to avoid full copying. It uses a sliding window comparison algorithm to identify differences, with the sliding step size set to W / 2 and the initial window starting position P=0.

[0052] Table 1. Window size is dynamically designed according to different business needs.

[0053] Step 1. Initialize parameters Input the primary node data D1 (length = L1), the backup node data D2 (length = L2), and the service type (eMBB / uRLLC / Default). The output is the modified data block. Step 2. Sliding window comparison A. Capture the window data of the primary node and backup node, W_D1=D1[P : P+W], W_D2 = D2[P : P+W]; B. Hierarchical hash calculation: CRC1 = CRC32(W_D1), CRC2 = CRC32(W_D2) C. If CRC1 = CRC2, then skip half a window, i.e., P = P + S, and continue to the next loop. D. If CRC1 != CRC2, then SHA-256 secondary verification is required: H1 = SHA256(W_D1), H2 = SHA256(W_D2); E. If H1 = H2, then proceed to step C. F. Conversely, it is necessary to locate the difference boundary: Diff_Start = P, Diff_End = find_boundary(D1,D2, P, P+W). G. After locating the difference boundary, extract the change block: DB=D1[Diff_Start : Diff_End] Step 3. Compression and Output If the database contains text, Zstandard compression is used, which offers faster compression ratios and speeds. If the database contains binary data, LZ4 compression is used, resulting in extremely fast decompression and low CPU overhead. For very small databases (<128B), they may be transmitted directly without compression to avoid compression overhead. Then, a transmission packet is generated, with the format: sequence number | start position | end position | compressed data.

[0054] 1) Fault recovery and consistency guarantee: When incremental synchronization is briefly interrupted due to network jitter and then resumed, the backup node can compare its own OpLog sequence number with that of the master node, pull the missing OpLog, replay it, and catch up with the progress.

[0055] When an incremental synchronization channel is detected to have been inactive for an extended period or when strong consistency guarantees are required (such as before a master-slave switch), switch directly to transaction log synchronization mode to ensure complete data consistency.

[0056] The master node persists the OpLog until it is confirmed that all backup nodes have successfully applied the log or the corresponding incremental update.

[0057] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A distributed core network collaborative system based on dynamic perception and intelligent decision-making, characterized in that, include: The system comprises a terminal access layer, a dynamic discovery layer, an intelligent decision-making layer, and a data synchronization layer; among which, The terminal access layer is used to receive connection requests from various terminal devices. The dynamic discovery layer consists of different core network nodes, and each core network node deploys a lightweight probe LSP to monitor and collect the status of each node. It periodically broadcasts the status information of its own node to the multicast group via UDP multicast, listens for LMDP messages from other nodes in the multicast group, and maintains a real-time, in-memory neighbor node topology table. The intelligent decision layer is used to receive real-time node status and topology information from the dynamic discovery layer, as well as business SLA requirements from the business layer, run the dynamic weight decision engine, determine the optimal node, and send routing instructions to the terminal access layer or the corresponding node. The data synchronization layer is responsible for synchronizing relevant state data from the original node to the new node when the decision involves node switching or state transition.

2. The distributed core network collaborative system based on dynamic perception and intelligent decision-making according to claim 1, characterized in that, The dynamic discovery layer monitors and collects the status of each node's hardware layer, operating system layer, network stack layer, and service layer; the message format for broadcasting its own status includes: version|node ID|timestamp|load weight|link quality|geographical location|.

3. The distributed core network collaborative system based on dynamic perception and intelligent decision-making according to claim 2, characterized in that, The link quality is a comprehensive score calculated based on the most recently detected RTT, jitter, and packet loss rate. score=100×(1-loss)×(1-min(1,jitter / 10))×(1- min(1,(rtt-10) / 100)) Where loss represents packet loss rate, jitter represents jitter, and RTT represents packet loss rate.

4. The distributed core network collaborative system based on dynamic perception and intelligent decision-making according to claim 1, characterized in that, The intelligent node runs a dynamic weight decision engine, and the process for determining the optimal node is as follows: Based on the candidate node list and business SLA requirements, calculate the priority score of all eligible candidate nodes and select the one with the highest score as the optimal target node; at the same time, generate a queue of backup nodes in descending order of score for quick switching.

5. The distributed core network collaborative system based on dynamic perception and intelligent decision-making according to claim 4, characterized in that, The priority calculation formula is as follows: Where α, β, and γ are the set weights, Load comes from the load weight in the message; LinkQuality comes from the link quality score in the message; and Distance is calculated based on the geographical location and request source location in the message.

6. The distributed core network collaborative system based on dynamic perception and intelligent decision-making according to claim 5, characterized in that, The weights are dynamically adjusted based on the business type: When the business type is eMBB: α=0.3, β=0.7, γ=0.0; When the business type is uRLLC: α = 0.4, β = 0.5, γ = 0.1; When the service type is mMTC: α=0.6, β=0.3, γ=0.1; In other cases, DEFAULT: α=0.4, β=0.5, γ=0.

1.

7. The distributed core network collaborative system based on dynamic perception and intelligent decision-making according to claim 4, characterized in that, The intelligent decision-making layer further operates a real-time avoidance mechanism, which is as follows: the decision engine will exclude nodes marked as FAULT / SUSPECT, nodes whose load exceeds the dynamic threshold, and nodes whose link quality is lower than the minimum requirement in real time; wherein, SUSPECT nodes are nodes that have not been detected with a heartbeat for N consecutive cycles, and FAULT nodes are nodes that have not been detected with a heartbeat for N+1 consecutive cycles.

8. The distributed core network collaborative system based on dynamic perception and intelligent decision-making according to claim 1, characterized in that, The data synchronization layer performs dual-channel data synchronization, specifically as follows: Main channel: Used for efficient state synchronization triggered periodically or by events, transmitting changed data blocks, and using a sliding window comparison algorithm to identify differences; Auxiliary channel: Used to continuously record all state change operations.

9. The distributed core network collaborative system based on dynamic perception and intelligent decision-making according to claim 8, characterized in that, Each log entry for a state change includes: operation type, data key, value before operation, value / parameter after operation, timestamp, and transaction ID.

10. A collaborative method for a distributed core network collaborative system based on any one of claims 1-9, characterized in that, The specific process is as follows: The dynamic discovery layer continuously monitors the status of all nodes and pushes the real-time topology and node health status to the intelligent decision-making layer. The intelligent decision-making layer determines the optimal node based on the real-time node status and SLA requirements, and sends routing instructions to the terminal access layer or the corresponding node. If the decision involves node switching or state migration, the data synchronization layer is responsible for synchronizing the relevant state data from the original node to the new node to ensure business continuity.

Images