Lossless self-healing method and system based on fttr digital twin and distributed prediction

Abstract

This application discloses a lossless self-healing method and system based on FTTR digital twins and distributed prediction. The method includes: maintaining digital twins on both the FTTR master gateway and FTTR sub-gateways, employing a synchronization mechanism combining periodic full-scale and event-triggered incremental synchronization; the FTTR sub-gateways using a lightweight fault prediction model to infer in real time, predicting software faults and reporting them; the master gateway coordinating the digital twins of the faulty gateway and its neighboring gateways to enter a virtual sandbox environment, where each twin instance runs diagnostic algorithms in parallel, reaching consensus on the root cause of the fault based on a majority voting mechanism, and using a virtual clock to accelerate the deduction of the optimal repair solution; the faulty gateway performing minimally invasive repair operations while maintaining uninterrupted data plane forwarding; and the cloud optimizing the model through federated learning and distributing it. This application achieves zero service interruption during the fault repair process, improving overall system performance and diagnostic accuracy.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and more specifically, to a lossless self-healing method and system based on FTTR digital twins and distributed prediction. Background Technology

[0002] In existing FTTR (Fiber to The Room) systems, the TR069 platform, OLT, or plug-in management system are typically used for remote management and fault handling of terminal devices. However, in actual operation, when network failures occur, these management methods often require manual intervention, resulting in long response times, high maintenance costs, and negatively impacting user experience.

[0003] To address these issues, existing technologies typically run a master intelligent program on the main gateway and slave intelligent programs on the sub-gateways. The master intelligent program performs self-diagnosis of faults on the main gateway and each sub-gateway. After diagnosing a fault, it performs automatic repairs by restarting the device, resetting the configuration, or updating the firmware.

[0004] However, the existing solutions described above still have the following shortcomings in practical applications: Repair operations all involve "reset" or "reboot," requiring service interruption, which disrupts current network services; diagnostic and decision-making authority is highly centralized in the main gateway, with sub-gateways only allowed to act autonomously after a network outage. This results in the sub-gateways' local awareness capabilities and computing resources being underutilized for the vast majority of the time, while the main gateway bears a significant computational and communication load; the main gateway needs to simultaneously handle global knowledge learning tasks from the cloud and real-time local traffic scheduling tasks; and the inference of complex models consumes processing resources required for real-time services, making it difficult to meet the requirements of low network latency and rapid response while ensuring diagnostic accuracy.

[0005] Therefore, existing technologies are still unable to simultaneously achieve non-destructive repair, high real-time response, and high diagnostic accuracy. Summary of the Invention

[0006] This application aims to address the technical problems in traditional FTTR networks, such as the inevitable service interruption caused by repair operations, the idle edge resources due to centralized diagnostic decision-making, and the resource competition between global knowledge learning and real-time response.

[0007] To achieve the above objectives, this application provides a lossless self-healing method based on FTTR digital twins and distributed prediction, applied to a system consisting of one FTTR master gateway and multiple FTTR sub-gateways, comprising the following steps: State synchronization steps: On the FTTR master gateway and each of the FTTR sub-gateways, a digital twin synchronized with the operating state of the corresponding physical gateway is maintained; the synchronization adopts a mechanism combining periodic full synchronization and event-triggered incremental synchronization. Fault prediction steps: Distributed fault prediction units deployed on each FTTR sub-gateway continuously collect time-series data of physical layer and system resources, and input the data into a lightweight fault prediction model that has undergone knowledge distillation and quantization for inference; when the probability of any software fault occurring exceeds a preset threshold, an incremental state synchronization is triggered to update the latest state of the current physical gateway to the local digital twin, and then a predictive fault report is generated and reported to the FTTR main gateway; Collaborative diagnostic steps: After receiving the predictive fault report, the FTTR master gateway identifies the gateway where the software fault occurred as the faulty gateway and initiates a diagnostic task. It coordinates the digital twins of the faulty gateway and at least one other gateway directly connected to the faulty gateway in the physical network topology to jointly load and instantiate a virtual sandbox environment. The virtual sandbox environment is a software runtime environment that is completely isolated from the physical network data plane and is used to simulate and verify the repair solution in an isolated environment. Consensus simulation steps: In the virtual sandbox environment, the participating digital twins run diagnostic algorithms in parallel, and vote on the root cause of the failure based on the distributed consensus protocol to reach a consensus; after reaching a consensus, the virtual clock is used to accelerate the simulation execution of various repair strategies, simulate their effects, and select the optimal lossless repair solution. Lossless repair steps: The FTTR master gateway distributes the optimal lossless repair scheme to the faulty gateway, and the faulty gateway completes the repair by performing operations that do not affect the core data plane forwarding work, while maintaining uninterrupted service connections during the repair process; Model iteration steps: Upload the success rate and effect data of this repair to the cloud management system. The cloud management system uses the data to start federated learning training, optimize the global fault prediction model and perform knowledge distillation, and then distribute the updated lightweight model to each gateway.

[0008] Optionally, in the state synchronization step, the mechanism combining periodic synchronization and event-triggered synchronization specifically involves: performing full state synchronization at preset time intervals and immediately performing incremental state synchronization upon detecting a preset critical event; the preset time interval is dynamically configured according to the system load; the preset critical events include at least one of configuration changes, abnormal process exits, and physical layer link state changes.

[0009] In some implementations, the timing data of the physical layer and system resources in the fault prediction step includes signal-to-noise ratio, bit error rate before forward error correction, optical module transmit and receive optical power, CPU utilization and memory utilization; the software faults include memory leaks, configuration conflicts or firmware interaction defects.

[0010] For example, in the fault prediction step, the lightweight fault prediction model that has undergone knowledge distillation and quantization is specifically an LSTM-1DCNN hybrid model that has undergone knowledge distillation and INT8 quantization.

[0011] Specifically, in the consensus deduction step, the virtual clock speed-up is achieved by setting the clock frequency of the virtual sandbox to 10 to 50 times the physical clock frequency.

[0012] Specifically, in the consensus deduction step, the voting on the root cause of the fault based on the distributed consensus protocol is specifically a majority voting mechanism; the majority voting mechanism is specifically: the FTTR main gateway initiates a diagnostic consensus task with a preset time limit, and when more than half of the nodes participating in the vote determine the same root cause of the fault, a consensus is reached.

[0013] Preferably, in the consensus deduction step, the preset time limit is 5 to 15 seconds; if a consensus is not reached within the preset time limit, the diagnostic consensus task is terminated and the relevant data is reported to the cloud management system.

[0014] Specifically, in the lossless repair step, the operations that do not affect the operation of the data plane forwarding core include at least one of the following operations: sending a smooth restart signal to the control plane software process; updating hardware or kernel forwarding table entries through the Netlink channel; and using a hot patching mechanism to fix software defects.

[0015] This application also provides a lossless self-healing system based on FTTR digital twin and distributed prediction, which includes an FTTR main gateway, multiple FTTR sub-gateways and a cloud management system; The FTTR sub-gateway is equipped with a distributed fault prediction unit and a digital twin engine. The distributed fault prediction unit is used to collect time-series data of the local physical layer and system resources, and input the data into a lightweight fault prediction model that has undergone knowledge distillation and quantization for inference. When the probability of predicting any software fault exceeds a preset threshold, an incremental state synchronization is triggered to update the current state of the physical gateway to the local digital twin, and then a predictive fault report is generated and reported to the FTTR main gateway. The digital twin engine is used to maintain a digital twin that is synchronized with the operating state of the corresponding physical gateway. Its synchronization mechanism is configured to combine periodic full synchronization and event-triggered incremental synchronization. The FTTR main gateway is equipped with a collaborative diagnosis and simulation module and a digital twin engine. The collaborative diagnosis and simulation module, upon receiving the predictive fault report, identifies the gateway experiencing the software fault as the faulty gateway, initiates a diagnostic task, coordinates the digital twins of the faulty gateway and at least one other gateway directly connected to the faulty gateway in the physical network topology, and instantiates them in a virtual sandbox environment completely isolated from the physical network data plane. It also enables each digital twin instance to run diagnostic algorithms in parallel within the virtual sandbox environment, votes on the root cause of the fault based on a distributed consensus protocol to reach a consensus, and utilizes a virtual clock to accelerate the simulation execution of various repair strategies, simulate their effects, and select the optimal lossless repair solution. The FTTR master gateway is also used to distribute the optimal lossless repair scheme to the faulty gateway; the faulty gateway is used to complete the repair by performing operations that do not affect the core operation of data plane forwarding, and to maintain uninterrupted service connections during the repair process; The cloud management system is used to receive repair success rate and effect data, use the data to start federated learning training, optimize the global fault prediction model and perform knowledge distillation, and distribute the updated lightweight model to each gateway.

[0016] Preferably, the operations that do not affect the operation of the data plane forwarding core include at least one of the following operations: sending a smooth restart signal to the control plane software process; updating hardware or kernel forwarding table entries through the Netlink channel; and using a hot patching mechanism to fix software defects.

[0017] The lossless self-healing method and system based on FTTR digital twins and distributed prediction provided in this application have the following beneficial effects: This application uses digital twin technology to mirror the state and behavior of the physical network into a virtual space. This allows repair operations that might otherwise disrupt services to be pre-verified in a virtual sandbox. Only solutions verified as lossless are then sent to the physical gateway for execution. In this way, user service connections are maintained during fault repair, resolving the conflict between repair operations and service continuity. Specifically, simulating multiple repair strategies and predicting their effects in the virtual sandbox allows for the early identification of solutions that could cause service interruptions, ensuring that the actual repairs do not affect the core data plane forwarding operations, thereby achieving zero service interruption. This application pushes fault prediction capabilities down to the edge of the FTTR sub-gateway, utilizing the idle computing resources of the sub-gateway for local real-time inference, while retaining collaborative diagnosis and decision-making at the main gateway. This architecture, combining edge prediction with central collaboration, not only offloads the computing load of the main gateway but also reduces fault response latency. Deploying lightweight models that have undergone knowledge distillation and INT8 quantization on the sub-gateway enables efficient operation on resource-constrained embedded devices, with a single inference cycle taking less than 50 milliseconds, achieving early warning and rapid reporting of faults. This application introduces a multi-twin parallel diagnosis and consensus voting mechanism, leveraging the redundancy and diversity of multiple twins in a distributed system to jointly determine the root cause of a failure. Compared to a single decision point, this approach can improve the accuracy of locating the root cause of complex or implicit software failures and reduce the risk of single-point misjudgment. In addition, this application also adopts virtual clock speed-up technology to compress the repair effect that takes a long time to observe into a short time in the virtual environment, thereby speeding up the selection of the optimal solution and improving the overall self-healing efficiency of the system. Attached Figure Description

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

[0019] Figure 1 This is a schematic diagram of the structure of a lossless self-healing system based on FTTR digital twin and distributed prediction according to an embodiment of this application; Figure 2 This is a flowchart illustrating the lossless self-healing method based on FTTR digital twins and distributed prediction according to an embodiment of this application. Figure 3 A diagram illustrating lossless repair of conflicts configured in FTTR sub-gateways in a home setting; Figure 4 A schematic diagram illustrating the non-destructive repair of memory leaks in the QoS module of the FTTR main gateway in an enterprise scenario; Figure 5 This diagram illustrates the early prediction of firmware defects in FTTR sub-gateways after changes in the network environment. Detailed Implementation

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

[0021] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0022] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0023] (1) FTTR main gateway: refers to the core gateway device in the fiber to room network, which is responsible for connecting with the optical line terminal (OLT) and managing multiple FTTR sub-gateways.

[0024] (2) FTTR sub-gateway: refers to the extended gateway device connected to the FTTR main gateway, which is responsible for extending the fiber optic network to each room.

[0025] (3) A digital twin is a software entity that is a complete mirror image of the physical gateway in terms of its operating status, configuration parameters, and traffic model.

[0026] (4) A virtual sandbox environment is a software operating environment that is completely isolated from the physical network data plane and is used to simulate and verify repair solutions.

[0027] (5) Minimally invasive repair operations refer to operations that do not affect the core work of data plane forwarding, including smooth process restart, hot table update and function-level hot patching.

[0028] Please see Figure 2 This application provides a lossless self-healing method based on FTTR digital twin and distributed prediction. The method includes a state synchronization step, a fault prediction step, a collaborative diagnosis step, a consensus deduction step, a lossless repair step, and a model iteration step.

[0029] State synchronization steps: On the FTTR master gateway and each FTTR sub-gateway, a digital twin synchronized with the corresponding physical gateway's operational state is maintained. This synchronization employs a mechanism combining periodic full synchronization and event-triggered incremental synchronization. The digital twin is used to provide an initial state consistent with the physical gateway for subsequent virtual sandbox diagnostics. Periodic full synchronization ensures long-term consistency, while event-triggered incremental synchronization ensures timely updates of critical states, reducing communication overhead while maintaining accuracy.

[0030] Fault prediction steps: Distributed fault prediction units deployed on each FTTR sub-gateway continuously collect time-series data of the physical layer and system resources, and input this data into a lightweight fault prediction model that has undergone knowledge distillation and quantization for inference. When the predicted probability of any software fault exceeds a preset threshold, an incremental state synchronization is triggered, updating the latest state of the current physical gateway to the local digital twin. Then, a predictive fault report is generated and reported to the FTTR main gateway. This transforms fault detection from passive response to proactive prediction, decentralizing prediction computation to the edge of the FTTR sub-gateway to reduce the load on the FTTR main gateway, and shortening fault response latency through local real-time inference. The preset threshold can be set to 90% by default, and the system can adaptively fine-tune it based on historical false alarm rates, ranging from 85% to 95%. When the false alarm rate is high, it can be temporarily increased to 95% to reduce the operation frequency; when there is a high sensitivity to missed alarms, it can be reduced to 85%.

[0031] Collaborative Diagnostic Steps: After receiving the predictive fault report, the FTTR master gateway identifies the gateway experiencing the software fault as the faulty gateway and initiates a diagnostic task. It coordinates the digital twins of the faulty gateway and at least one other gateway directly connected to it in the physical network topology to jointly load and instantiate a virtual sandbox environment. The virtual sandbox environment is a software runtime environment completely isolated from the physical network data plane, used to simulate and verify repair solutions in an isolated environment. This overcomes the limitations of centralized single-point decision-making, utilizes the diversity of multiple gateway twins to improve diagnostic accuracy, and ensures that the complete isolation between the virtual sandbox and the physical data plane does not affect actual business operations.

[0032] Consensus simulation steps: In the virtual sandbox environment, participating digital twin instances run diagnostic algorithms in parallel, and vote on the root cause of the fault based on a distributed consensus protocol to reach a consensus. After reaching a consensus, multiple repair strategies are simulated and executed at double speed using a virtual clock, their effects are simulated, and the optimal lossless repair solution is selected. Parallel diagnosis by multiple digital twins combined with consensus voting eliminates the risk of single-point misjudgment. The virtual clock acceleration compresses the simulation of long-term repair effects into a short time. Simulating multiple repair strategies in the virtual sandbox ensures the effectiveness of the solution deployed to the physical gateway.

[0033] Lossless Repair Steps: The FTTR master gateway distributes the optimal lossless repair solution to the faulty gateway. The faulty gateway completes the repair by performing operations that do not affect the operation of the data plane forwarding core, while maintaining uninterrupted service connections during the repair process. By repairing only specific software modules or configuration items, a complete machine restart or reset is avoided. The data plane forwarding core remains operational, user service connections are uninterrupted, and the repair operation is completed quickly.

[0034] Model iteration steps: The success rate and effectiveness data of this repair are uploaded to the cloud management system. The cloud management system uses this data to initiate federated learning training, optimize the global fault prediction model, and perform knowledge distillation. The updated lightweight model is then distributed to each gateway. This enables the system to continuously learn and improve, resulting in a continuous increase in prediction accuracy and repair success rate, forming a closed-loop optimization mechanism.

[0035] Through the above steps, the lossless self-healing method based on FTTR digital twin and distributed prediction provided in this application embodiment is achieved as follows: (1) When in normal operation, the digital twins of each gateway maintain consistency with the physical gateway in real time through a mechanism that combines periodic full synchronization with event-triggered incremental synchronization, providing an accurate initial state for subsequent fault diagnosis and simulation. (2) When in the fault prediction state, the distributed fault prediction unit on the FTTR sub-gateway continuously collects the time-series data of the physical layer and system resources, and uses the lightweight fault prediction model to perform real-time reasoning. When the predicted probability of software fault occurrence exceeds the preset threshold, the predictive fault report is triggered. When in the collaborative diagnosis state, the collaborative diagnosis and inference module of the FTTR main gateway initiates a diagnosis task, coordinates the digital twins of the fault gateway and its neighboring gateways to enter the virtual sandbox environment, and each twin runs the diagnosis algorithm in parallel. Based on the distributed consensus protocol, the root cause of the fault is voted on, and after reaching a consensus, the virtual clock is used to accelerate the simulation and execution of various repair strategies. (3) When in a lossless repair state, the optimal repair scheme verified by the virtual sandbox is sent to the fault gateway, and the fault gateway performs a minimally invasive repair operation. During the entire repair process, the data plane forwarding core remains operational and the service connection is not interrupted. (4) When the model is in the iteration state, the repair data is uploaded to the cloud management system, the cloud starts federated learning training, optimizes the global fault prediction model and performs knowledge distillation, and distributes the updated lightweight model to each gateway to form a closed-loop optimization.

[0036] The above six steps form an organic whole through strict sequential dependencies: the state synchronization step provides an accurate initial state foundation for fault prediction, collaborative diagnosis, and consensus deduction, ensuring the reliability of subsequent deductions; the fault prediction step relies on the data provided by state synchronization and simultaneously triggers the collaborative diagnosis step, reducing the load on the FTTR main gateway by offloading prediction calculations to the edge of the FTTR sub-gateway, thus achieving resource collaboration from the edge to the center; the collaborative diagnosis step responds to the reporting of fault predictions, providing a virtual sandbox environment and participating nodes for the consensus deduction step; the consensus deduction step relies on multiple twins coordinated by collaborative diagnosis, ensuring diagnostic accuracy and the effectiveness of repair solutions through parallel diagnosis, consensus voting, and virtual clock acceleration; the lossless repair step executes the optimal solution selected by consensus deduction, achieving zero service interruption, and simultaneously providing repair data for the model iteration step; the model iteration step uses the data from fault prediction and lossless repair to optimize the global model and distribute it to each gateway, improving fault prediction performance and forming a positive feedback loop. Each step complements the other, working together to resolve conflicts between repair and business, imbalances between the center and the edge, and contradictions between global knowledge and real-time response, thus forming a complete FTTR self-healing method that can simultaneously achieve non-destructive repair, high real-time performance, and high diagnostic accuracy.

[0037] In an optional implementation of the state synchronization step, the mechanism combining periodic synchronization and event-triggered synchronization specifically involves: performing full state synchronization at preset time intervals, and immediately performing incremental state synchronization upon detecting a preset critical event; the preset time interval is dynamically configured according to system load, for example, the period is set to 60 seconds under light load, and can be extended to 120 seconds under heavy load or nighttime periods; event-triggered incremental synchronization ensures timely updates of critical states. The preset critical events include at least one of configuration changes, abnormal process exits, and changes in physical layer link states. Performing full state synchronization at preset time intervals ensures that the digital twin and the physical gateway remain consistent over a longer time scale. Immediately performing incremental state synchronization upon detecting critical events such as configuration changes, abnormal process exits, or changes in physical layer link states enables the digital twin to reflect important state changes of the physical gateway in a timely manner. This mechanism combining periodic synchronization and event-triggered synchronization significantly reduces communication overhead and computational resource consumption compared to continuous full synchronization while ensuring state accuracy.

[0038] In a specific implementation of the fault prediction step, the time-series data of the physical layer and system resources are divided into two groups: (1) Physical layer group: signal-to-noise ratio (SNR), bit error rate before forward error correction (pre-FEC BER), optical module transmit power (Tx Power) and receive power (Rx Power). Among them, SNR and BER have a negative correlation. The typical linkage rule is: when SNR>25dB, BER<1e-8; when SNR<15dB, BER may rise to more than 1e-5; when the Tx / Rx power difference exceeds 15dB, it indicates a link abnormality; (2) Resource group: CPU utilization (user+system, excluding interrupts) and memory utilization (including cache). When CPU>80% and memory growth rate>5% / hour, the risk of memory leakage is predicted. This data is periodically (default 1 second) reported to the local digital twin, and the sampling frequency can be temporarily increased to 200ms by event triggering. The multi-dimensional time-series data input enables the fault prediction model to monitor the system operating status from multiple angles. In addition, the software faults mentioned include memory leaks, configuration conflicts, or firmware interaction defects, which clarifies the target scope of fault prediction and makes model training and inference more focused.

[0039] In another specific implementation of the fault prediction step, the lightweight fault prediction model after knowledge distillation and quantization is specifically a hybrid LSTM-1DCNN model that has undergone knowledge distillation and INT8 quantization. This lightweight model, after knowledge distillation and quantization, can execute efficiently on resource-constrained embedded devices, with a single inference time typically less than 100 milliseconds and low CPU utilization (e.g., no more than 5%). Its specific performance depends on the hardware platform and model complexity. This significantly reduces model complexity and computational resource requirements while maintaining predictive capabilities, enabling the model to run efficiently on resource-constrained edge devices.

[0040] In an optional implementation of the consensus simulation step, the virtual clock acceleration specifically involves setting the clock frequency of the virtual sandbox to 10 to 50 times the physical clock frequency. The virtual clock acceleration is typically set to 10 to 30 times the physical clock, and should not exceed 50 times. Excessive acceleration can cause deviations in time-related logic within the virtual sandbox (such as TCP retransmission timers and heartbeat detection), reducing the reliability of the simulation results. In practical applications, the acceleration ratio can be adaptively selected for different fault types: for slow-changing faults such as memory leaks, a 50x acceleration is allowed; for faults involving protocol state machine timeouts, the acceleration ratio is limited to no more than 10 times, or acceleration is disabled for accurate simulation. During accelerated simulation, the state of each digital twin within the virtual sandbox progresses synchronously with the accelerated clock, and its execution logic remains consistent with the physical environment. After the accelerated simulation is completed, the system selects the optimal lossless repair solution based on preset evaluation indicators (such as service retention rate and resource usage trends).

[0041] In another optional implementation of the consensus deduction step, the voting on the root cause of the fault based on the distributed consensus protocol specifically employs a majority voting mechanism. The majority voting mechanism is as follows: the FTTR main gateway initiates a diagnostic consensus task with a preset time limit. Consensus is reached when more than half of the participating nodes determine the same root cause of the fault. Using a majority voting mechanism, the FTTR main gateway initiates a diagnostic consensus task with a preset time limit. Each participating twin independently provides its determined root cause of the fault and its confidence level. Consensus is reached when more than half of the participating nodes (e.g., at least 2 votes out of 3 nodes, or at least 3 votes out of 5 nodes) determine the same root cause of the fault. The required percentage can be appropriately reduced when the number of nodes is small. The multi-node voting mechanism eliminates the risk of single-point misjudgment; the requirement of more than half of the nodes being consistent ensures the reliability of the consensus; the preset time limit prevents the diagnostic process from waiting indefinitely; and it is simple to execute.

[0042] In a preferred embodiment of the consensus deduction step, the preset time limit is 5 to 15 seconds. If a consensus is not reached within the preset time limit or all deduced repair solutions pose a risk of service interruption, the diagnostic consensus task is terminated, and relevant data is reported to the cloud management system. In specific implementation, manual intervention or a backup plan (e.g., delaying restart during a service idle period) can also be implemented. The diagnostic consensus task with a preset time limit is initiated by the FTTR main gateway. The time limit can be configured according to the fault type and real-time requirements. This time includes: loading the twin into the virtual sandbox, parallel diagnosis, voting and consensus, and virtual accelerated deduction (depending on the speedup ratio and deduction duration). If the physical gateway's computing resources are strained (e.g., CPU usage >70% for a long period), the actual time consumption may exceed the limit, and the system will terminate the automatic process and report an alarm. For services with extremely high real-time requirements (e.g., VoIP), automatic repair can be turned off in advance, and only the prediction results are reported. While ensuring sufficient time for diagnosis and voting, the entire consensus process is ensured to be completed before the actual occurrence of the fault. If a consensus cannot be reached within the time limit, the diagnostic consensus task will be terminated and the relevant data will be reported to the cloud management system to avoid missing the best repair opportunity due to long waiting time, and to provide data to the cloud for subsequent analysis and model optimization.

[0043] In one specific embodiment of the lossless repair step, the operations that do not affect the operation of the data plane forwarding core include at least one of the following: sending a smooth restart signal to the control plane software process, enabling the process to restart without interrupting services; updating hardware or kernel forwarding table entries via the Netlink channel to achieve hot updates of configuration items; and using a hot patching mechanism to fix software defects, repairing specific software defects without restarting the entire system. These operations do not affect the operation of the data plane forwarding core, ensuring uninterrupted service connections during the repair process.

[0044] The specific implementation of hot patching depends on the gateway's operating system and software architecture: for Linux systems that support kernel livepatch, the atomic patching interface provided by the kernel is used directly; for embedded systems that do not support livepatch, function pointer redirection or pre-reserving jump slots in critical functions (such as inserting nop instructions) can be used. The latter two methods are preferred under ARM architecture to avoid complex kernel patch dependencies.

[0045] In one optional implementation, the model iteration step specifically involves uploading the success rate and effectiveness data of this repair (including fault characteristics and system states before and after repair) to the cloud management system after anonymization. The cloud management system uses this data (i.e., the success rate and effectiveness data of this repair) to initiate a federated learning framework for model optimization: the FTTR main gateway and each FTTR sub-gateway maintain personalized fault prediction models locally, aggregating only the update gradients or weights of model parameters in the cloud management system, without uploading the original data. Considering the potential differences in network traffic patterns and device types in different gateway environments (e.g., home, enterprise), the cloud management system can use weighted averaging or domain similarity-based clustering methods during aggregation to generate a global base model. This global base model, after knowledge distillation and compression into a lightweight version, is distributed to the FTTR main gateway and each FTTR sub-gateway as initial parameters for local models or for fine-tuning. For gateways with significant data distribution deviations, some local parameters can be retained to balance generality and personalization.

[0046] like Figure 1 As shown in the embodiments of this application, a lossless self-healing system based on FTTR digital twin and distributed prediction is also proposed, including an FTTR master gateway, multiple FTTR sub-gateways and a cloud management system.

[0047] The FTTR sub-gateway is equipped with a distributed fault prediction unit and a digital twin engine. The distributed fault prediction unit collects time-series data of the local physical layer and system resources, inputs this data into a lightweight fault prediction model that has undergone knowledge distillation and quantization for inference. When the probability of predicting any software fault exceeds a preset threshold, it triggers an incremental state synchronization, updating the current physical gateway state to the local digital twin, and then generates a predictive fault report and reports it to the FTTR main gateway. The digital twin engine maintains a digital twin synchronized with the operating state of the corresponding physical gateway. Its synchronization mechanism combines periodic full synchronization with event-triggered incremental synchronization. The distributed fault prediction unit collects time-series data of the local physical layer and system resources, inputs it into the lightweight fault prediction model for inference, and generates a predictive fault report when the probability of predicting a software fault exceeds a preset threshold, reporting it to the FTTR main gateway to achieve real-time fault early warning at the edge. The digital twin engine maintains a digital twin synchronized with the physical gateway's operating state through a mechanism combining periodic full synchronization and event-triggered incremental synchronization, providing an accurate digital copy for subsequent diagnostic simulations.

[0048] The FTTR master gateway is equipped with a collaborative diagnosis and simulation module and a digital twin engine. The collaborative diagnosis and simulation module, upon receiving the predictive fault report, identifies the gateway experiencing the software fault as the faulty gateway and initiates a diagnostic task. It coordinates the digital twins of the faulty gateway and at least one other gateway directly connected to it in the physical network topology to enter and instantiate a virtual sandbox environment completely isolated from the physical network data plane. Within the virtual sandbox environment, it enables each digital twin instance to run diagnostic algorithms in parallel, votes on the root cause of the fault based on a distributed consensus protocol to reach a consensus, and utilizes a virtual clock to accelerate the simulation execution of various repair strategies, simulate their effects, and select the optimal lossless repair solution. The FTTR master gateway also distributes the optimal lossless repair solution to the faulty gateway. The faulty gateway completes the repair by performing operations that do not affect the core data plane forwarding operations, and maintains uninterrupted service connections during the repair process. After receiving a predictive fault report, the collaborative diagnosis and simulation module identifies the faulty gateway and initiates a diagnostic task. It coordinates the digital twins of the faulty gateway and its neighboring gateways to enter a virtual sandbox environment completely isolated from the physical network data plane. Within the virtual sandbox, the digital twins run diagnostic algorithms in parallel, reaching consensus on the root cause of the fault through voting based on a distributed consensus protocol. A virtual clock is used to accelerate the simulation and execution of various repair strategies, and the optimal lossless repair solution is selected based on the simulation's effects. Finally, the optimal solution is distributed to the faulty gateway. The digital twin engine provides the twins participating in the diagnostic simulation.

[0049] The cloud management system receives repair success rate and effectiveness data, uses this data to initiate federated learning training, optimizes the global fault prediction model, performs knowledge distillation, and distributes the updated lightweight model to each gateway. This process of receiving repair success rate and effectiveness data, initiating federated learning training to optimize the global fault prediction model, performing knowledge distillation, and distributing the updated lightweight model to each gateway enables continuous iterative optimization of the model.

[0050] The FTTR main gateway, multiple FTTR sub-gateways, and the cloud management system form a three-tiered collaborative architecture from the edge to the center and then to the cloud, realizing a closed-loop process of fault prediction, diagnostic simulation, and repair execution. The distributed fault prediction unit of the FTTR sub-gateways relies on synchronized status data provided by the digital twin engine for accurate inference, while simultaneously providing fault warnings to the FTTR main gateway. The collaborative diagnosis and simulation module of the FTTR main gateway responds to reports from the FTTR sub-gateways, utilizing multiple twins coordinated by the digital twin engines of the FTTR sub-gateways and the FTTR main gateway to perform parallel diagnosis and simulation in a virtual sandbox, providing validated repair solutions for the FTTR sub-gateways. The cloud management system utilizes the repair data from the FTTR sub-gateways to optimize the model, providing a better prediction model for the distributed fault prediction unit of the FTTR sub-gateways.

[0051] The operations in this system that do not affect the operation of the data plane forwarding core include at least one of the following: sending a smooth restart signal to the control plane software process; updating hardware or kernel forwarding table entries through the Netlink channel; and using a hot patching mechanism to fix software defects.

[0052] The solution proposed in this application is compatible with existing hardware. For example, Realtek RTL9619C, Broadcom BCM58712, and MaxLinearURX851 can be used as the FTTR main gateway in this application, or MediaTek / Dafcom AI gateway solutions (such as AN7581CT+NPU) can also be used as the FTTR main gateway in this application, while ZTE Microelectronics ZX279129 and Broadcom BCM6756 can be used as FTTR sub-gateways in this application. Of course, higher margin and scalability can also be obtained by upgrading to AI-enhanced chips. For example, there are already mature gateway chip solutions with NPU (Neural Processing Unit) on the market, covering multiple levels from lightweight IoT to high-performance fiber optic gateways. For example, Rockchip / Advantech (RK3588 core board) and MediaTek / Dafcom (AI fiber optic gateway platform), etc.

[0053] The present application will be described below with specific application examples.

[0054] Example 1: Lossless repair of FTTR sub-gateway configuration conflicts in a home scenario. For example... Figure 3As shown, the network topology in this embodiment includes one FTTR main gateway and three FTTR sub-gateways (FTTR sub-gateway A, FTTR sub-gateway B, and FTTR sub-gateway C). Home users can play online games and stream 4K videos at home.

[0055] During the state synchronization step, the digital twin engine of FTTR sub-gateway A performs full state synchronization every 30 seconds, and immediately performs incremental state synchronization when critical events such as configuration changes are detected, maintaining a digital twin that is synchronized with the operating state of the physical gateway of FTTR sub-gateway A.

[0056] In the fault prediction step, the distributed fault prediction unit of FTTR sub-gateway A collects time-series data of the physical layer and system resources. The collection frequency can be dynamically adjusted according to the monitoring indicators. For slowly changing indicators (such as memory usage and signal-to-noise ratio), 1 to 2 Hz is used, along with bit error rate, optical module transmit / receive power, CPU utilization, and memory utilization. For bursty indicators (such as instantaneous spikes in bit error rate), 10 Hz burst sampling or event-triggered sampling is used. Under the default configuration, the system continuously collects and caches the most recent 60 samples at 1 Hz. When the model input requires higher resolution, it can be temporarily increased to 5 Hz. The distributed fault prediction unit inputs the data into an LSTM-1DCNN hybrid model that has undergone knowledge distillation and INT8 quantization for inference. This lightweight model can be executed on mainstream FTTR sub-gateway SoCs (such as ZTE Microelectronics ZX279129 and Broadcom BCM6756) with sub-second cycles. The inference latency is typically in the tens of milliseconds, and the additional CPU load does not exceed 10%. Specific values ​​vary depending on chip generation and firmware optimization; for example, latency can rise to around 100ms on the Cortex-A7 platform. When the predicted probability of a VLAN configuration conflict exceeds a preset threshold (e.g., 85% to 95%, adjustable based on false alarm tolerance), a "Predictive Failure: VLAN Configuration Conflict" report is generated and sent to the FTTR master gateway. In actual testing in a typical home network environment, the prediction accuracy at this threshold setting is approximately 85% to 90%, indicating a certain possibility of false alarms. Further optimization will be achieved through cloud-based federated learning.

[0057] In the collaborative diagnostic step, upon receiving the report, the FTTR master gateway immediately initiates the collaborative diagnostic and simulation module. The FTTR master gateway identifies FTTR sub-gateway A as the faulty gateway and initiates a diagnostic task, coordinating the digital twins of FTTR sub-gateway A and FTTR sub-gateway B (where the uplink ports whose traffic may be affected) to enter a virtual sandbox environment based on Linux namespaces.

[0058] In the consensus simulation step, within the virtual sandbox, the twin of FTTR sub-gateway A, running a decision tree algorithm, determined a VLAN conflict; the twin of FTTR sub-gateway B, running a Bayesian network algorithm, determined a broadcast domain anomaly risk; and the twin of the FTTR main gateway, after comprehensive judgment, also determined a VLAN conflict. The three reached a consensus through a majority voting mechanism, with a 2:1 vote (FTTR sub-gateway A and the FTTR main gateway being consistent). Subsequently, the "redistribution and hot activation of VLAN 98" scheme was simulated in the virtual sandbox using a virtual clock speed multiplier (50x) to verify that there were no loops or storm risks upstream and downstream. The entire simulation process was completed within 3 seconds.

[0059] In the lossless repair process, the FTTR master gateway pushes the instruction to "hot-swap the VLAN bound to the guest SSID of FTTR sub-gateway A from 101 to 98" to FTTR sub-gateway A. FTTR sub-gateway A updates the VLAN mapping table of the switching chip through the Netlink channel. The entire process does not involve physical port jitter or system restart, and all connected devices' game and video sessions remain uninterrupted. In a laboratory gigabit wired environment without external interference, test results show that the average latency increased from 12ms to 13ms (fluctuation ±2ms); the packet loss rate was less than 0.1%; and the throughput decreased by approximately 0.5% to 1.5%. It should be noted that in a real home environment, due to factors such as wireless channel contention and terminal differences, latency fluctuations may reach ±10ms, the packet loss rate may rise to 0.5%, and the throughput decrease may reach 3% to 5%. However, the core indicator of uninterrupted service connectivity is still met.

[0060] During the model iteration process, the success rate and effectiveness data of this repair operation are uploaded to the cloud management system. The cloud uses this data to start federated learning training, optimize the global fault prediction model and perform knowledge distillation, and then distribute the updated lightweight model to each FTTR sub-gateway.

[0061] In this embodiment, when a VLAN configuration conflict occurs, the distributed fault prediction unit of FTTR sub-gateway A detects that the predicted probability of a conflict between its assigned VLAN ID and a newly connected smart TV exceeds 90% (configurable, ranging from 85% to 95%). This triggers the generation of a predictive fault report, which is then reported to the FTTR main gateway. In actual testing, the false negative rate at this threshold is approximately 5% to 8%, and the false positive rate is approximately 10% to 12%. This can be gradually optimized through cloud-based federated learning. Upon receiving the report, the collaborative diagnosis and simulation module of the FTTR main gateway immediately initiates a diagnostic task, coordinating the digital twins of FTTR sub-gateway A and FTTR sub-gateway B to enter a virtual sandbox environment. Each twin runs different diagnostic algorithms in parallel within the virtual sandbox. A majority voting mechanism is used to vote on the root cause of the fault, and after reaching a consensus, a virtual clock is used to accelerate the simulation and execution of the repair strategy. Due to the adoption of the digital twin pre-simulation verification mechanism, the repair scheme is fully verified in the virtual sandbox, ensuring the non-destructive nature of the repair process. By employing multi-twin parallel diagnosis and consensus voting mechanisms, the risk of single-point misjudgment is eliminated, improving diagnostic accuracy. Furthermore, the use of virtual clock acceleration technology compresses long-term repair effect simulations into a short timeframe, enabling rapid verification.

[0062] In the same fault scenario, if a traditional device restart repair method is used, the service will be completely interrupted during the repair process, and the duration of the interruption depends on the device restart time (usually 30 seconds to 1 minute). If relying on platforms such as TR069 to automatically trigger the restart, the total time from fault detection to repair completion is generally about 1 to 2 minutes; if manual remote login is required for diagnosis and operation, the total time may reach several minutes to more than ten minutes. The non-destructive repair solution proposed in this application can achieve zero service interruption, and the total time of the entire prediction, diagnosis, simulation, and repair process is usually within a few seconds.

[0063] Example 2: Lossless Repair of Memory Leak in FTTR Main Gateway QoS Module in an Enterprise Scenarios. This example demonstrates a scenario where the fault occurs within the FTTR main gateway itself during peak office hours, and showcases different repair operation types. Figure 4 As shown, the network topology of this embodiment includes one FTTR main gateway and two FTTR sub-gateways (FTTR sub-gateway A and FTTR sub-gateway B).

[0064] In the fault prediction step, the FTTR master gateway's own distributed fault prediction unit discovered that the memory usage of its QoS scheduling process showed a typical leakage curve. Based on the memory usage growth rate (approximately 8%~12% / hour), it predicted that all traffic scheduling would fail due to memory exhaustion in 25 to 40 minutes, generating an internal report titled "Predictive Fault: FTTR Master Gateway QoS Process Memory Leak".

[0065] During the collaborative diagnostic process, the FTTR master gateway initiates this fault as a task, commanding itself and the digital twins of the master and slave devices responsible for forwarding core services—FTTR sub-gateway A and FTTR sub-gateway B—to enter a virtual sandbox environment.

[0066] During the consensus simulation process, all three counterparts diagnosed the root cause as "QoS daemon memory leak." In the virtual sandbox, they jointly simulated a solution: a smooth restart of the qosd process. The simulation results showed that during the restart, traffic would automatically bypass the process, only temporarily losing priority scheduling and reverting to best-effort forwarding, but service connections remained uninterrupted and recovered immediately after the restart.

[0067] In the lossless repair process, after consensus was reached, the physical system of the FTTR main gateway performed a smooth restart of the qosd daemon. The FTTR main gateway achieved a smooth restart of the process by sending a kill -HUP smooth restart signal to the control plane software process. The restart took approximately 1 to 2 seconds, during which ongoing video conferences and VoIP calls were not interrupted, and were forwarded by the FTTR main gateway's hardware forwarding engine only on a best-effort basis. After the restart, QoS scheduling returned to normal, and the memory leak issue was resolved. Network performance was monitored during the repair process. In an internal enterprise test environment (gigabit wired backbone, simulating 30 concurrent users), the test results were as follows: the average latency increased from 20ms to 25ms to approximately 30ms to 40ms (affected by the temporary QoS failure during the smooth restart), but recovered after the restart; there was no significant lag in online conferences and VoIP calls during the period; the packet loss rate was between 0.1% and 0.3%; and the throughput briefly decreased by approximately 5% to 8%, with the decrease varying with the number of concurrent connections. In an internal enterprise simulation test environment (30 concurrent users), all video conferences and VoIP calls remained uninterrupted, but two VoIP terminals reported brief voice stutters of approximately 0.5 seconds. The test results indicate that this recovery solution can achieve lossless business recovery under typical enterprise loads. Actual performance may vary depending on factors such as traffic patterns and hardware performance.

[0068] In this embodiment, when the QoS process is in a memory leak state, the distributed fault prediction unit of the FTTR main gateway detects that the memory usage of the QoS scheduling process exhibits a typical leakage curve, predicting that all traffic scheduling will fail due to memory exhaustion after 30 minutes, triggering the generation of a predictive fault report. Upon receiving the report, the collaborative diagnosis and deduction module of the FTTR main gateway immediately initiates a diagnosis task, coordinating the digital twins of the FTTR main gateway itself, FTTR sub-gateway A, and FTTR sub-gateway B to enter a virtual sandbox environment. Each twin runs a diagnostic algorithm in parallel within the virtual sandbox, diagnosing the root cause as a memory leak in the QoS daemon process. After reaching a consensus, a smooth restart scheme for the qosd process is deduced and executed. Due to the adoption of process smooth restart technology, traffic automatically bypasses the process during restart, only temporarily losing priority scheduling, but service connections remain uninterrupted, achieving lossless repair. The use of multi-twin parallel diagnosis and consensus voting mechanisms eliminates the risk of single-point misjudgment and improves diagnostic accuracy.

[0069] Example 3: Early prediction of firmware defects in FTTR sub-gateways after changes in network environment. For example... Figure 5 As shown, the network topology in this embodiment includes one FTTR master gateway and two FTTR sub-gateways (FTTR sub-gateway A and FTTR sub-gateway C). This is after the operator's network upgrade.

[0070] In the fault prediction step, the distributed fault prediction unit of FTTR sub-gateway C, through a lightweight model, discovered that when it interacts with the upstream new OLT, the negotiation state machine of a certain optical module frequently enters an error branch. This pattern is highly consistent with a "firmware interaction defect" feature in the cloud model library. Based on the current error frequency of the state machine (about 15 times per hour) and the trend, the model predicts that there will be a risk of frequent optical module resets leading to disconnection within 3 to 7 days (with an error of ±2 days), and then generates a report.

[0071] In the collaborative diagnostic step, the FTTR master gateway initiates a task, and the FTTR master gateway, FTTR sub-gateway C, and the twin of FTTR sub-gateway A cascaded with C enter the virtual sandbox environment.

[0072] During the consensus simulation process, the diagnostic results in the virtual sandboxes of all three systems pointed to "firmware defects in a specific OLT environment". Subsequently, they simulated the execution of a "firmware patch hot update" recently issued from the cloud in the virtual sandbox, verifying that after the patch was loaded, the state machine interaction returned to normal and did not affect the cascading services of FTTR sub-gateway A.

[0073] In the non-destructive repair process, after the FTTR main gateway confirms the virtual sandbox verification is successful, it pulls the firmware patch from the cloud and asynchronously pushes it to FTTR sub-gateway C. During service downtime, FTTR sub-gateway C performs a hot patch repair on the optical module's control firmware. Throughout the entire process, the FTTR sub-gateway does not restart, and the user side is completely unaware, successfully avoiding a potential future network outage. After the hot patch is loaded, it is verified in a simulated carrier network environment in the laboratory (including the upstream OLT and cascaded sub-gateways). Limited by laboratory conditions (no external interference, room temperature of about 25℃, fixed flow model), the performance test results before and after the repair are as follows: (1) Latency change: the average latency before the repair was about 17 ms to 19 ms, and after the repair it was basically the same, with fluctuations within ±2ms (including normal network jitter); (2) Packet loss rate: no obvious packet loss was detected before and after the repair, and the measured packet loss rate was less than 0.05%, which can be regarded as no packet loss in the laboratory environment; in the actual network, the packet loss rate may increase slightly due to factors such as sudden congestion; (3) Throughput: the bidirectional throughput was stable at around 900Mbps (about 90% to 95% of the line speed), and the change before and after the repair was within the measurement error range (±3%); (4) State machine error injection frequency: before the repair, the firmware state machine entered the error branch at a frequency of about 12 per hour. The frequency dropped to 18 times (average 15 times); after repair, the frequency dropped to close to 0 times (actual observation was 0 to 1 times per hour, possibly caused by occasional interference), and the state machine returned to normal; (5) Prediction accuracy: on the limited test sample set of this type of firmware defect (about 200 positive and negative samples in total), the identification accuracy of the fault prediction model was about 88% to 94%, the false negative rate was about 6% to 10%, and the false positive rate was about 5% to 8%. It should be noted that the data is limited by the sample distribution and laboratory environment, and the actual accuracy of the live network may fluctuate. It needs to be continuously optimized through federated learning iteration.

[0074] In this embodiment, when the firmware interaction is in a defective state, the distributed fault prediction unit of FTTR sub-gateway C detects that during its interaction with the upstream new OLT, the negotiation state machine of a certain optical module frequently enters an erroneous branch, predicting that it may go offline due to frequent optical module resets several days later, triggering the generation of a predictive fault report. Upon receiving the report, the collaborative diagnosis and deduction module of the FTTR main gateway immediately initiates a diagnosis task, coordinating the digital twins of the FTTR main gateway, FTTR sub-gateway C, and FTTR sub-gateway A to enter a virtual sandbox environment. Each twin runs a diagnostic algorithm in parallel within the virtual sandbox, diagnosing the root cause as a firmware defect in a specific OLT environment. After reaching a consensus, a firmware patch hot update scheme is deduced and executed. Because function-level hot patching technology is used, the repair process does not require restarting the device, and the user side is completely unaware, achieving lossless repair. The use of multi-twin parallel diagnosis and consensus voting mechanisms eliminates the risk of single-point misjudgment and improves diagnostic accuracy.

[0075] As can be seen from the above, this application has at least the following technical effects: (1) This application realizes real-time fault warning on the edge side through the distributed fault prediction unit and digital twin engine of the FTTR sub-gateway. The collaborative diagnosis and deduction module of the FTTR main gateway coordinates multiple digital twins to diagnose in parallel and deduce the optimal repair solution in the virtual sandbox. The cloud management system continuously optimizes the prediction model through federated learning, forming a three-level collaborative architecture from the edge to the center and then to the cloud. (2) The digital twin provides an accurate initial state for fault prediction, fault prediction provides a triggering condition for collaborative diagnosis, collaborative diagnosis provides a verification scheme for non-destructive repair, non-destructive repair provides training data for model iteration, and model iteration provides a better model for fault prediction. Each feature constitutes an inseparable coupled system. (3) The combination of digital twin pre-simulation verification and process-level minimally invasive repair achieves non-destructive repair process; the combination of edge distributed prediction and central collaborative diagnosis achieves global system performance improvement; and the combination of multi-twin parallel diagnosis and consensus voting achieves improved diagnostic accuracy. (4) The lightweight model enables real-time local prediction by the FTTR sub-gateway, the virtual clock speed-up shortens the simulation time, the majority voting mechanism ensures consensus reliability, and operations such as smooth restart, Netlink entry update, and dynamic binary instrumentation ensure zero-interruption service repair. The combination of periodic synchronization and event-triggered synchronization reduces communication overhead while ensuring accuracy, multi-dimensional time-series data improves prediction accuracy, federated learning enables continuous model optimization, and the overall system realizes a closed-loop process of fault prediction, diagnosis simulation, and repair execution, significantly improving the reliability and self-healing capability of the FTTR system.

[0076] The above descriptions are merely embodiments of this application. Commonly known technical solutions or characteristics are not described in detail here. It should be noted that those skilled in the art can make various modifications and improvements without departing from the technical solution of this application. These modifications and improvements should also be considered within the scope of protection of this application, and will not affect the effectiveness of the application or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A lossless self-healing method based on FTTR digital twin and distributed prediction, applied to a system consisting of one FTTR master gateway and multiple FTTR sub-gateways, characterized in that, Includes the following steps: State synchronization steps: On the FTTR master gateway and each of the FTTR sub-gateways, a digital twin synchronized with the operating state of the corresponding physical gateway is maintained; the synchronization adopts a mechanism combining periodic full synchronization and event-triggered incremental synchronization. Fault prediction steps: Distributed fault prediction units deployed on each FTTR sub-gateway continuously collect time-series data of physical layer and system resources, and input the data into a lightweight fault prediction model that has undergone knowledge distillation and quantization for inference; when the probability of any software fault occurring exceeds a preset threshold, an incremental state synchronization is triggered to update the latest state of the current physical gateway to the local digital twin, and then a predictive fault report is generated and reported to the FTTR main gateway; Collaborative diagnostic steps: After receiving the predictive fault report, the FTTR master gateway identifies the gateway where the software fault occurred as the faulty gateway and initiates a diagnostic task. It coordinates the digital twins of the faulty gateway and at least one other gateway directly connected to the faulty gateway in the physical network topology to jointly load and instantiate a virtual sandbox environment. The virtual sandbox environment is a software runtime environment that is completely isolated from the physical network data plane and is used to simulate and verify the repair solution in an isolated environment. Consensus simulation steps: In the virtual sandbox environment, the participating digital twin instances run diagnostic algorithms in parallel, and vote on the root cause of the failure based on the distributed consensus protocol to reach a consensus; after reaching a consensus, the virtual clock is used to accelerate the simulation execution of various repair strategies, simulate their effects, and select the optimal lossless repair solution. Lossless repair steps: The FTTR master gateway distributes the optimal lossless repair scheme to the faulty gateway, and the faulty gateway completes the repair by performing operations that do not affect the core data plane forwarding work, while maintaining uninterrupted service connections during the repair process; Model iteration steps: Upload the success rate and effect data of this repair to the cloud management system. The cloud management system uses the data to start federated learning training, optimize the global fault prediction model and perform knowledge distillation, and then distribute the updated lightweight model to each gateway.

2. The method according to claim 1, characterized in that, In the state synchronization step, the mechanism combining periodic synchronization and event-triggered synchronization is specifically as follows: full state synchronization is performed at a preset time interval, and incremental state synchronization is performed immediately when a preset key event is detected; the preset time interval is dynamically configured according to the system load; the preset key event includes at least one of configuration change, abnormal process exit, and physical layer link state change.

3. The method according to claim 1, characterized in that, In the fault prediction step, the time-series data of the physical layer and system resources include signal-to-noise ratio, bit error rate before forward error correction, optical module transmit power and optical receive power, CPU utilization and memory utilization; the software faults include memory leaks, configuration conflicts or firmware interaction defects.

4. The method according to claim 1, characterized in that, In the fault prediction step, the lightweight fault prediction model that has undergone knowledge distillation and quantization is specifically a hybrid LSTM-1DCNN model that has undergone knowledge distillation and INT8 quantization.

5. The method according to claim 1, characterized in that, In the consensus deduction step, the virtual clock speed-up specifically involves setting the clock frequency of the virtual sandbox to 10 to 50 times the physical clock frequency.

6. The method according to claim 1, characterized in that, In the consensus deduction step, the voting on the root cause of the fault based on the distributed consensus protocol specifically adopts a majority voting mechanism; the majority voting mechanism specifically means that the FTTR main gateway initiates a diagnostic consensus task with a preset time limit, and when more than half of the nodes participating in the vote determine the same root cause of the fault, a consensus is reached.

7. The method according to claim 6, characterized in that, In the consensus deduction step, the preset time limit is 5 to 15 seconds; if a consensus is not reached within the preset time limit, the diagnostic consensus task is terminated and the relevant data is reported to the cloud management system.

8. The method according to claim 1, characterized in that, In the lossless repair step, the operations that do not affect the operation of the data plane forwarding core include at least one of the following operations: sending a smooth restart signal to the control plane software process; updating hardware or kernel forwarding table entries through the Netlink channel; and using a hot patching mechanism to fix software defects.

9. A lossless self-healing system based on FTTR digital twin and distributed prediction, characterized in that, Includes the FTTR main gateway, multiple FTTR sub-gateways, and a cloud management system; The FTTR sub-gateway is equipped with a distributed fault prediction unit and a digital twin engine. The distributed fault prediction unit is used to collect time-series data of local physical layer and system resources, and input the data into a lightweight fault prediction model that has undergone knowledge distillation and quantization for inference. When the probability of predicting any software fault exceeds a preset threshold, an incremental state synchronization is triggered to update the current state of the physical gateway to the local digital twin, and then a predictive fault report is generated and reported to the FTTR main gateway. The digital twin engine is used to maintain a digital twin that is synchronized with the operating status of the corresponding physical gateway. Its synchronization mechanism is configured to combine periodic full synchronization with event-triggered incremental synchronization. The FTTR main gateway is equipped with a collaborative diagnosis and simulation module and a digital twin engine. The collaborative diagnosis and simulation module, upon receiving the predictive fault report, identifies the gateway experiencing the software fault as the faulty gateway, initiates a diagnostic task, coordinates the digital twins of the faulty gateway and at least one other gateway directly connected to the faulty gateway in the physical network topology, and instantiates them in a virtual sandbox environment completely isolated from the physical network data plane. It also enables each digital twin instance to run diagnostic algorithms in parallel within the virtual sandbox environment, votes on the root cause of the fault based on a distributed consensus protocol to reach a consensus, and utilizes a virtual clock to accelerate the simulation execution of various repair strategies, simulate their effects, and select the optimal lossless repair solution. The FTTR master gateway is also used to distribute the optimal lossless repair scheme to the faulty gateway; the faulty gateway is used to complete the repair by performing operations that do not affect the core operation of data plane forwarding, and to maintain uninterrupted service connections during the repair process; The cloud management system is used to receive repair success rate and effect data, use the data to start federated learning training, optimize the global fault prediction model and perform knowledge distillation, and distribute the updated lightweight model to each gateway.

10. The system according to claim 9, characterized in that, The operations that do not affect the core operation of the data plane forwarding include at least one of the following: sending a smooth restart signal to the control plane software process; updating hardware or kernel forwarding table entries through the Netlink channel; and using a hot patching mechanism to fix software defects.

Images