Network fault processing method, electronic equipment and program product

Abstract

The invention provides a network fault processing method, electronic equipment and a program product, and relates to the technical field of computers. The method comprises the following steps: acquiring physical layer data, network layer data and application layer data of each edge node through a lightweight diagnosis engine deployed by each edge node; the physical layer data, the network layer data and the application layer data are input into a global fault analysis model constructed based on federated learning, global fault features are obtained, and the global fault features are unified feature representation representing cross-device and cross-protocol stack fault association relationships; generating a fault processing strategy adaptive to the current scene through a dynamic strategy matrix generator based on the global fault features in combination with the current network load state, the service priority and the equipment computing power distribution; and executing the fault processing strategy, and based on execution result feedback, updating the cross-level fault analysis model and the dynamic strategy matrix generator. According to the embodiment of the invention, the resource utilization rate can be effectively improved, and the efficiency of autonomous operation and maintenance is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a network fault handling method, electronic device, and program product. Background Technology

[0002] With the rapid popularization of smart home devices, the number of terminals connected to home networks continues to grow, and the network architecture is becoming increasingly complex, placing higher demands on the network's self-maintenance capabilities. Current mainstream fault handling solutions mostly rely on independent diagnosis of single devices or centralized network management systems, which generally suffer from three major technical bottlenecks: First, fault detection is limited to a single protocol layer (such as focusing only on Wi-Fi connection status), making it difficult to identify cross-layer related faults such as application layer service degradation caused by physical layer anomalies (such as optical power fluctuations); second, repair strategies mostly adopt fixed rules (such as forced restarts or reconnections), lacking dynamic perception and adaptation to real-time network load, service priorities, and device computing power distribution, resulting in low repair efficiency and even resource waste; third, centralized diagnosis requires uploading original user data, posing a risk of privacy leaks, and the problem of data silos between devices is serious, making collaborative intelligence impossible.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] This disclosure provides a network fault handling method, electronic device, and program product, which at least to some extent improves the existing smart home network fault handling methods, which are difficult to effectively identify cross-device and cross-protocol stack related faults and rely on static repair strategies, which cannot be dynamically adjusted according to real-time network status and business needs.

[0005] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0006] According to one aspect of this disclosure, a network fault handling method is provided, comprising: The lightweight diagnostic engine deployed on each edge node acquires physical layer data, network layer data, and application layer data of each edge node. Physical layer data, network layer data, and application layer data are input into a global fault analysis model built based on federated learning to obtain global fault features. Global fault features are a unified feature representation that characterizes the fault correlation relationships across devices and protocol stacks. Based on global fault characteristics, combined with the current network load status, service priority and device computing power distribution, a fault handling strategy adapted to the current scenario is generated through a dynamic strategy matrix generator. Execute fault handling strategies and update the cross-level fault analysis model and dynamic strategy matrix generator based on the execution results.

[0007] In one embodiment of this disclosure, after executing the fault handling strategy, the method further includes: By using the lightweight diagnostic engine deployed on each edge node, physical layer data, network layer data, and application layer data of each edge node are obtained again. Based on the reacquired physical layer data, network layer data, and application layer data, determine whether the fault has been recovered after the fault handling strategy is executed.

[0008] In one embodiment of this disclosure, the method further includes: If the fault is not resolved after the fault handling strategy is executed, or if no fault handling strategy is matched by the dynamic strategy matrix generator, the fault information is reported to the network management system.

[0009] In one embodiment of this disclosure, a lightweight diagnostic engine deployed on each edge node is used to obtain physical layer data, network layer data, and application layer data of each edge node. This includes obtaining the local feature matrix and fault label corresponding to each edge node sent by the lightweight diagnostic engine deployed on each edge node. The local feature matrix and fault label are obtained by the edge fault analysis model in the lightweight diagnostic engine processing the physical layer data, network layer data, and application layer data. Based on physical layer data, network layer data and application layer data, fault feature correlation analysis is performed to obtain global fault features, including: global fault features are generated by aggregating and generating global fault features based on the local feature matrix and fault labels corresponding to each edge node through a global fault analysis model. Among them, the edge fault analysis model and the global fault analysis model are trained through federated learning, and encrypted gradient aggregation is used during the training process to protect data privacy.

[0010] In one embodiment of this disclosure, after reporting fault information to the network management system, the method further includes: after the fault is repaired manually or automatically, using the fault information and its corresponding repair strategy as new samples to train the edge fault analysis model and the global fault analysis model, and updating the lightweight diagnostic engine deployed on each edge node based on the training results.

[0011] In one embodiment of this disclosure, a lightweight diagnostic engine is deployed in an optical network unit, gateway device, and / or terminal.

[0012] In one embodiment of this disclosure, based on global fault characteristics and combined with the current network load status, service priority, and device computing power distribution, a fault handling strategy adapted to the current scenario is generated through a dynamic policy matrix generator. This includes: determining current state data based on global fault characteristics and combined with the current network load status, service priority, and device computing power distribution; the current state data includes fault type, fault priority, and device load; inputting the current state data into the dynamic policy matrix generator, and outputting the currently executed action as the fault handling strategy; wherein the dynamic policy matrix generator is trained based on a reinforcement learning algorithm, and its reward function provides positive and negative feedback based on whether the fault is successfully repaired.

[0013] In one embodiment of this disclosure, the execution of a fault handling strategy includes: calling on end-edge-cloud three-level resources through a resource coordination scheduler to perform operations including cross-device computing power pooling, channel switching, quality of service adjustment, or link reconfiguration.

[0014] In one embodiment of this disclosure, the method further includes: collecting physical layer signal strength, transport layer handshake delay and application layer service quality indicators through a protocol stack probe module, constructing a full protocol stack runtime digital twin, and providing multi-dimensional feature input for a global fault analysis model.

[0015] According to another aspect of this disclosure, an electronic device is provided, comprising: a memory for storing instructions; and a processor for calling the instructions stored in the memory to implement the above-described network fault handling method.

[0016] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the network fault handling method described above.

[0017] According to another aspect of this disclosure, a computer program product is provided, which stores instructions that, when executed by a computer, cause the computer to perform the network fault handling method described above.

[0018] According to another aspect of this disclosure, a chip is provided, including at least one processor and an interface; the interface is used to provide program instructions or data to the at least one processor; the at least one processor is used to execute the program instructions to implement the network fault handling method described above.

[0019] The network fault handling method, electronic device, and program product provided in this disclosure, by integrating multi-dimensional data from the physical layer, network layer, and application layer, and utilizing federated learning to construct a global fault analysis model, effectively achieves accurate correlation identification of faults across devices and protocol stacks, overcoming the shortcomings of traditional single-point detection in locating link-level or collaborative faults. Based on global fault characteristics and combined with real-time context such as network load, service priority, and device computing power, a dynamic policy matrix generator generates scenario-adaptive repair policies, significantly improving the targeting and resource utilization efficiency of repairs, and avoiding misoperations or resource waste caused by fixed policies. The federated learning mechanism completes model collaborative training without uploading original sensitive data, ensuring user privacy and security, and meeting compliance requirements in smart home scenarios. By feeding back policy execution results to update the fault analysis model and policy generator, a closed-loop self-evolution mechanism is formed, possessing continuous learning and optimization capabilities, which can continuously improve the accuracy of fault diagnosis and the success rate of repair. Furthermore, this method does not rely on a centralized control node, supports edge autonomy, enhances robustness and scalability, and is suitable for large-scale heterogeneous smart home network environments.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0022] Obviously, the accompanying drawings described below are merely some embodiments of this disclosure. Those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0023] Figure 1 This diagram illustrates a network fault handling method according to an embodiment of the present disclosure. Figure 2 This diagram illustrates another network fault handling method according to an embodiment of the present disclosure. Figure 3 This diagram illustrates the network fault handling system and its associated scenario in an embodiment of the present disclosure. Figure 4 This diagram illustrates the network fault handling logic in an embodiment of the present disclosure. Figure 5 This diagram illustrates a flowchart of a network fault handling method in an embodiment of this disclosure. Figure 6 This diagram illustrates the logic of the federated learning model in an embodiment of this disclosure. Figure 7This diagram illustrates the training and iteration process of the federated learning model in an embodiment of this disclosure. Figure 8 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0024] To facilitate understanding of the technical solutions of this disclosure, the disclosure will be further described below with reference to the accompanying drawings.

[0025] The terms "first" and "second," etc., in this disclosure, claim, and drawings are used only to distinguish different objects and not to describe a particular order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0026] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this disclosure. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0027] In this disclosure, "at least one (item)" means one or more, "more than" means two or more, "at least two (items)" means two or three or more, and "and / or" is used to describe the relationship between related objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist simultaneously, where A and B can be singular or plural. "Or" indicates that there can be two relationships, such as only A exists and only B exists; when A and B are not mutually exclusive, it can also mean that there are three relationships, such as only A exists, only B exists, and A and B exist simultaneously. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items. For example, at least one (item) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c".

[0028] As the smart home ecosystem gains wider acceptance, smart home devices (such as smart cameras, smart speakers, and environmental sensors) are experiencing explosive growth, leading to an exponential increase in the complexity of home networks. According to a report from the China Academy of Information and Communications Technology (CAICT), the average number of connected devices in a home has reached over 15, and existing maintenance strategies and passive fault repair strategies are no longer sufficient to meet the maintenance requirements of the expanding smart home ecosystem.

[0029] The inventors discovered the following problems with traditional maintenance strategies: The inefficiency of fixed strategies is mainly reflected in insufficient scenario adaptability, such as the failure of the strategy when resetting the link is affected by network load fluctuations or business priority conflicts; and serious resource waste, as fixed detection strategies perform redundant repair steps for a large number of simple faults, such as Wi-Fi channel interference, which consumes a lot of resources.

[0030] There are blind spots in the diagnosis of cross-layer faults. This is mainly reflected in the fact that traditional fault detection can only detect single-layer faults (such as optical modems or terminals). When there are link layer conflicts, protocol layer incompatibility, or abnormal negotiation handshakes, they cannot be diagnosed. Data silos lead to a lack of correlation analysis in the smart home ecosystem, resulting in the need for manual intervention to investigate.

[0031] This disclosure aims to overcome the aforementioned technical bottlenecks by achieving decentralized dynamic fault repair through layered collaboration of local self-maintenance modules. This disclosure innovatively constructs a multi-level collaborative self-maintenance system based on a distributed edge intelligent architecture, achieving a technological leap through a three-layer innovative mechanism: The device-side embedded lightweight diagnostic engine enables millisecond-level real-time capture of physical layer anomaly features; A fault feature fusion analysis model based on federated learning between levels breaks through the dimensional limitations of traditional single-layer detection. A dynamic strategy matrix-driven autonomous repair mechanism enables efficient collaboration of end-edge-cloud resources.

[0032] This architecture creatively achieves technological advancements in three dimensions: improving fault location accuracy to achieve multi-level feature correlation analysis across protocol stacks, achieving sub-second closed-loop self-healing in terms of system response timeliness, and achieving cross-device dynamic reuse of edge computing resources in terms of resource utilization efficiency, thereby constructing a new paradigm of autonomous maintenance for smart homes without decentralized dependencies.

[0033] The deficiencies of the above solutions and the proposed solutions are the result of the inventors' practical experience and careful research. Therefore, the discovery process of the above problems and the solutions proposed in this disclosure below should be considered as the inventors' contributions to this disclosure.

[0034] It is understood that the data involved in this disclosure (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and provisions. Before using the technical solutions disclosed in the embodiments of this disclosure, users shall be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and their authorization shall be obtained.

[0035] The following detailed description of this exemplary implementation method is provided in conjunction with the accompanying drawings and embodiments.

[0036] Figure 1 This diagram illustrates a flowchart of a network fault handling method according to an embodiment of the present disclosure, such as... Figure 1 As shown, the network fault handling method provided in this embodiment includes S101-S104.

[0037] In S101, the physical layer data, network layer data and application layer data of each edge node are obtained through the lightweight diagnostic engine deployed on each edge node.

[0038] In some embodiments, the lightweight diagnostic engine is deployed on an optical network unit (ONU), gateway device, and / or terminal.

[0039] By deploying a lightweight diagnostic engine on edge nodes such as optical modems, gateways, and terminals, real-time data is acquired at the physical layer (e.g., optical power, channel interference), network layer (e.g., packet loss rate, DHCP conflicts), and application layer (e.g., video frame rate, service response latency). This step breaks through the limitations of single-layer detection, providing full-dimensional input for cross-protocol stack fault correlation analysis and achieving millisecond-level anomaly detection.

[0040] In S102, physical layer data, network layer data, and application layer data are input into a global fault analysis model built based on federated learning to obtain global fault features. Global fault features are a unified feature representation that characterizes the fault correlation relationships across devices and protocol stacks.

[0041] Multi-layered data from each edge node is input into a global fault analysis model built on federated learning. Without transmitting the original data, cross-device features are aggregated and fused through encrypted gradients to generate a unified global fault feature representing "cross-device, cross-protocol stack fault correlations". This step can solve the data silo problem, achieve collaborative diagnosis under privacy protection, and significantly improve the accuracy of identifying complex faults (such as link negotiation failure and resource conflicts).

[0042] In some embodiments, for the physical layer (optical modem), optical power data can be collected every 500ms, and an alarm can be triggered if the fluctuation exceeds ±0.5dBm; for the gateway layer, the Wi-Fi signal strength and packet loss rate reported by the terminal can be analyzed in real time through a federated learning model; in addition, application layer traffic characteristics can be detected and monitored (such as triggering a stuttering flag when the video stream frame rate drops by 30%).

[0043] In some embodiments, the protocol stack probe module can also collect physical layer signal strength, transport layer handshake delay and application layer service quality indicators to construct a full protocol stack runtime digital twin, providing multi-dimensional feature input for the global fault analysis model.

[0044] This disclosed embodiment utilizes a resource collaborative scheduler to uniformly schedule resources at the terminal, edge, and cloud levels, enabling efficient execution of fault repair actions. Cross-device computing power pooling dynamically reuses idle computing resources (such as calling nearby terminal NPUs to accelerate diagnosis), improving processing capabilities; channel switching, QoS (Quality of Service) adjustments, and link reconfiguration specifically optimize network transmission quality. The technical effects are: breaking down device resource silos, achieving elastic collaboration of heterogeneous resources, significantly improving the efficiency and success rate of complex fault repair; and precisely allocating resources according to policy requirements, ensuring a high-priority service experience while avoiding global resource waste, enhancing the overall autonomy and scalability of the system.

[0045] In S103, based on global fault characteristics, combined with the current network load status, service priority and device computing power distribution, a fault handling strategy adapted to the current scenario is generated through a dynamic policy matrix generator.

[0046] Based on global fault characteristics and considering current network load, service priorities (e.g., security monitoring over smart lighting), and device computing power distribution, a dynamic policy matrix generator outputs the optimal repair actions (e.g., channel switching, QoS adjustment, and computing power scheduling). This generator continuously optimizes policy selection through reinforcement learning. This step avoids a "one-size-fits-all" approach to repair, achieving efficient resource utilization and high-priority service assurance, thus improving repair success rate and timeliness.

[0047] In S104, the fault handling strategy is executed, and the cross-level fault analysis model and dynamic strategy matrix generator are updated based on the execution result feedback.

[0048] In some embodiments, for low-priority faults, the terminal may execute a restart command locally (taking less than 3 seconds); for medium-priority faults, the gateway may coordinate with the optical modem to adjust the QoS policy and switch the Wi-Fi channel; for high-priority faults, the optical modem may trigger system-level repair (such as link aggregation) and synchronously update the federated learning model.

[0049] The generated fault handling strategy is executed, and the repair result (success / failure) is used as a feedback signal to update the global fault analysis model and dynamic strategy matrix generator, forming a closed loop of "perception-decision-execution-learning". This enables the system to have continuous self-evolution capabilities, continuously improve diagnostic accuracy and strategy adaptability during long-term operation, and reduce the need for manual intervention.

[0050] The embodiments disclosed herein achieve a four-in-one self-maintenance capability for smart home networks, encompassing privacy and security, cross-layer collaboration, dynamic adaptation, and autonomous evolution.

[0051] Figure 2 This invention discloses a network fault handling method in an embodiment of the present invention, wherein S201-S204 are similar to S101-S104 above, and will not be described again here.

[0052] In S205, the physical layer data, network layer data and application layer data of each edge node are obtained again through the lightweight diagnostic engine deployed at each edge node. In S206, based on the reacquired physical layer data, network layer data, and application layer data, it is determined whether the fault has been recovered after the fault handling strategy is executed.

[0053] This embodiment of the disclosure achieves closed-loop confirmation of fault repair effectiveness by collecting multi-level data again after strategy execution and performing confirmatory analysis. This mechanism avoids the problem of "blind execution and inability to verify," ensuring the effectiveness of self-maintenance actions. If the fault is not restored, secondary diagnosis or manual reporting can be triggered in a timely manner, improving system reliability and user experience, while providing real feedback data for model iteration to support subsequent strategy optimization.

[0054] In some embodiments, if the fault is not recovered after the fault handling policy is executed, or if no fault handling policy is matched by the dynamic policy matrix generator, the fault information is reported to the network management system.

[0055] If the fault is not resolved after the fault handling strategy is executed, or the dynamic strategy matrix generator cannot generate an effective strategy, the system will automatically report the fault information, which includes multi-layer feature data, fault type, and attempted repair actions, to the network management system. Upon receiving the report, the network management system can generate a maintenance work order for manual intervention or in-depth analysis using a cloud-based knowledge base. After the fault is repaired, the case (including the effective repair solution) will be fed back to the federated learning framework to update the edge and global models.

[0056] This embodiment of the disclosure promptly reports fault information to the network management system when self-repair fails or no available strategy is available, ensuring that services are not interrupted for extended periods due to automation failure and improving system robustness. The reported information includes multi-layered features and repair records, facilitating precise manual location or in-depth cloud analysis. After repair, effective cases are fed back to update the federated learning model, achieving knowledge accumulation and model iteration, thereby enhancing the system's ability to autonomously handle similar future faults and forming a closed-loop operation and maintenance system of "automatic repair—manual backup—intelligent evolution".

[0057] In some embodiments, the physical layer data, network layer data, and application layer data of each edge node are obtained through a lightweight diagnostic engine deployed on each edge node, including: obtaining the local feature matrix and fault label corresponding to each edge node sent by the lightweight diagnostic engine deployed on each edge node; wherein, the local feature matrix and fault label are obtained by the edge fault analysis model in the lightweight diagnostic engine processing the physical layer data, network layer data, and application layer data. Based on physical layer data, network layer data and application layer data, fault feature correlation analysis is performed to obtain global fault features, including: global fault features are generated by aggregating and generating global fault features based on the local feature matrix and fault labels corresponding to each edge node through a global fault analysis model. Among them, the edge fault analysis model and the global fault analysis model are trained through federated learning, and encrypted gradient aggregation is used during the training process to protect data privacy.

[0058] This embodiment utilizes a lightweight edge-side diagnostic engine to extract local features from raw multi-layer data, generating a local feature matrix and fault labels, thus avoiding the uploading of raw sensitive data (such as video streams and audio). A cloud-based global fault analysis model then generates global fault features based on encrypted aggregated local model parameters, enabling collaborative diagnosis across devices and protocol stacks. The entire process employs a federated learning framework and encrypted gradient aggregation technology, effectively integrating fault knowledge from distributed heterogeneous devices while ensuring user privacy and preventing data from leaving the domain. This mechanism not only solves the privacy leakage and data silo problems inherent in traditional centralized analysis but also significantly improves the accuracy of identifying complex cross-layer faults. Simultaneously, it considers the deployment feasibility in edge computing resource-constrained scenarios, achieving a balance between privacy security, efficient diagnosis, and system scalability.

[0059] In some embodiments, after reporting fault information to the network management system, the above method further includes: after the fault is repaired manually or automatically, using the fault information and its corresponding repair strategy as new samples to train the edge fault analysis model and the global fault analysis model, and updating the lightweight diagnostic engine deployed on each edge node based on the training results.

[0060] This embodiment uses successfully repaired fault cases (including fault characteristics and corresponding strategies) as high-quality new samples, which are fed back into the federated learning framework for iterative training of edge and global fault analysis models. By continuously injecting real-world experience, the system continuously improves its ability to identify and handle complex or novel faults. Simultaneously, the updated model can optimize the lightweight diagnostic engine of each edge node, achieving long-term evolution in diagnostic accuracy and self-repair success rate.

[0061] In some embodiments, based on global fault characteristics and combined with the current network load status, service priority, and device computing power distribution, a fault handling strategy adapted to the current scenario is generated through a dynamic policy matrix generator. This includes: determining current state data based on global fault characteristics and combined with the current network load status, service priority, and device computing power distribution, wherein the current state data includes fault type, fault priority, and device load; inputting the current state data into the dynamic policy matrix generator and outputting the current execution action as the fault handling strategy; wherein the dynamic policy matrix generator is trained based on a reinforcement learning algorithm, and its reward function provides positive and negative feedback based on whether the fault is successfully repaired.

[0062] This disclosed embodiment constructs refined "current state data" by integrating global fault characteristics with real-time network context (such as load, service priority, and device computing power), and inputs this data into a dynamic policy matrix generator trained based on reinforcement learning, outputting the optimal execution action. Its reward mechanism uses the success or failure of repair as feedback signals, continuously optimizing the policy towards a higher success rate. The technical effects are reflected in: first, achieving scenario-adaptive decision-making, avoiding the failure of general policies on high-priority services (such as security video) or resource-constrained devices; second, dynamically balancing resources and user experience, for example, scheduling redundant computing power for collaborative repair under low load, and prioritizing critical services under high load; and third, through online reinforcement learning, enabling the system to cope with unknown or evolving fault modes, continuously improving the intelligence and robustness of the policy, significantly outperforming traditional methods using static rule bases or fixed threshold triggers.

[0063] In some embodiments, the execution of fault handling strategies includes: calling on edge-cloud level three resources through a resource coordination scheduler to perform operations including cross-device computing power pooling, channel switching, quality of service (QoS) adjustment, or link reconfiguration.

[0064] In some embodiments, the above-described network fault handling method can be applied to a network fault handling system, and the scenario framework of the network fault handling system can be as follows: Figure 3 As shown.

[0065] like Figure 3As shown, the network fault handling system mainly includes: a lightweight diagnostic engine, a federated analysis model, a dynamic policy matrix generator, a resource cooperative scheduler, and a protocol stack probe module. The federated analysis model can be the global fault analysis model described earlier.

[0066] The aforementioned architecture can be deployed on edge nodes of smart home devices, collecting physical layer signal characteristics, transport layer handshake protocols, and application layer business data in real time through a protocol stack probe module. A lightweight diagnostic engine performs millisecond-level real-time analysis of physical layer anomalies, comparing the diagnostic results with a cross-layer feature map constructed by a federated analysis model. When a protocol stack break or resource conflict is detected, a dynamic policy matrix generator generates an optimized combination of repair policies based on real-time network load and device computing power distribution. A resource coordination scheduler dynamically allocates redundant computing resources on the edge side according to the policy matrix, achieving cross-device resource reuse through an inter-device computing power pooling mechanism, ultimately forming a closed-loop self-healing link of "feature perception - intelligent judgment - policy generation - resource scheduling." During cross-layer fault repair, if cloud-based collaborative decision-making is involved, the system constructs a distributed fault knowledge base through a federated learning algorithm, enabling secure feature sharing and collaborative reasoning among edge nodes.

[0067] Lightweight diagnostic engine: Deployed at the device hardware layer, it achieves millisecond-level real-time detection of physical layer anomalies (such as channel interference and signal attenuation) through low-latency signal processing algorithms, and uses lightweight neural networks to extract features and predict hardware-level anomaly patterns.

[0068] Federated Analysis Model: Based on the horizontal federated learning framework, a feature fusion mechanism is constructed across devices and protocol layers. Fault feature correlation analysis between edge nodes is realized through encrypted parameter exchange, breaking through the traditional single-layer detection boundary and establishing a fault transmission relationship map of physical layer-protocol layer-business layer.

[0069] Dynamic policy matrix generator: Combining real-time network topology, service priority, and device computing power distribution status, it dynamically generates multi-dimensional repair policy combinations (such as channel switching weight, routing optimization coefficient, and computing power allocation ratio) through reinforcement learning to form an optimal policy matrix that adapts to the current network load.

[0070] Resource Coordination Scheduler: Based on the policy matrix, it implements dynamic orchestration of resources at the end-edge-cloud level, realizes cross-device pooling of redundant computing power through virtualization interfaces between devices, and supports second-level elastic scaling of GPU / NPU heterogeneous computing resources in the event of sudden failures.

[0071] Protocol stack probe module: Integrates a multi-protocol parsing engine (Wi-Fi / Bluetooth / Zigbee), continuously collects cross-layer data streams such as physical layer signal strength, transport layer handshake latency, and application layer QoS indicators, and constructs a full protocol stack runtime digital twin to provide multi-dimensional feature inputs for upper-layer analysis.

[0072] The fault reporting component issues an alarm and reports it to the network management server when a fault cannot be repaired autonomously, generating a fault work order.

[0073] like Figure 4 As shown, taking the optical modem penetration execution logic as an example, the execution logic for the above network fault handling is as follows: The physical layer diagnostic engine activates the optical signal quality sensing unit to monitor optical power in real time and generate OLT optical path status characteristics; The protocol stack feature correlation matrix inputs physical layer features into the distributed autonomous decision-making center of the intelligent gateway layer; The multimodal decision fusion engine integrates federated learning and reinforcement learning strategies to generate a dynamic policy matrix; QoS situational awareness and dynamic arbitrator analyze the policy matrix to drive a lightweight policy executor to implement network optimization; The terminal layer service quality probe continuously monitors the video stream quality and extracts service stream features through a lightweight application perception module; Privacy-preserving feature exchange nodes encrypt and securely share cross-device optical power features and service flow features; Business flow characteristics are fed back to the protocol stack feature correlation matrix, execution results are fed back to physical layer diagnosis, and strategy optimization instructions are cyclically updated to update the dynamic matrix; The system continuously optimizes its self-maintaining logic chain through a triple closed-loop feedback mechanism (features / execution / strategy).

[0074] In some embodiments, the network fault handling method disclosed herein can be as follows: Figure 5 As shown, the specific execution flow is as follows: Step 1: The lightweight diagnostic engine performs a self-diagnosis every 30 minutes. Some devices use the lightweight diagnostic engine and protocol stack probes to detect in real time whether there are any abnormalities in the physical layer information of the device. Step 2: If an anomaly is found, first attempt to self-repair the device (such as restarting, refreshing data, etc.); if it cannot be repaired, then report the fault characteristics. Step 3: The federated learning model identifies fault characteristics and transmits them to the dynamic policy matrix for fault decision-making; at the same time, the protocol stack probe module determines whether there are any protocol incompatibilities.

[0075] Step 4: If it is determined that there is no repair strategy, then report the fault and push it to the operator's network management system for fault notification; Step 5: If a repair strategy is determined, execute the online repair. For example, if the optical modem's optical power is abnormal, repair the fault by adjusting the port, QoS, etc. Step Six: Determine whether the fault has been repaired based on the latest diagnostic results returned by the lightweight diagnostic engine. If repaired, report the case. Step 7: If the fault is not repaired, report the fault information to the operator's network management system at the same time.

[0076] Step 8: Report fault cases to the federated learning model training module for policy updates and diagnostic engine upgrades.

[0077] Step three above can specifically include the following steps: Data collection: The dynamic policy matrix generator needs to collect data from multiple layers and devices. This data will serve as the basis for fault diagnosis and handling plan development. Physical layer data: Collects data such as optical power, bit error rate, and OLT optical path status from devices like optical modems. For example, the optical power monitoring module monitors optical power values ​​in real time and feeds them back to the dynamic policy matrix generator. Network layer data: Information from the gateway, such as Wi-Fi packet loss rate, channel interference intensity, and DHCP lease conflicts. This data reflects the stability and availability of network connections. Application layer data: Service flow characteristics provided by terminal devices such as smart cameras and smart speakers, such as video stuttering, service response time, and service priority marking.

[0078] Fault diagnosis, based on collected data, uses the dynamic policy matrix generator to determine whether a fault has occurred through the following methods: Threshold judgment: Normal range thresholds are set for various data types. When collected data exceeds these thresholds, a fault is considered likely. For example, if the normal range for optical power is set to ±0.5dBm, and optical power fluctuations reach ±0.8dBm, the optical modem is considered to be faulty. Rule matching: A series of rules are established to determine faults. For example, when the video service quality probe detects that the video frame rate is below 20fps (stuttering threshold) three times consecutively, and the network packet loss rate is higher than 5%, a video service fault is determined. Correlation analysis: The correlation between data at different layers is analyzed. When abnormal correlations occur, a fault is identified. For example, when the optical modem's optical power fluctuates abnormally, and the service response time of terminal devices significantly increases, a strong correlation exists between the two, indicating a cross-layer fault in the network.

[0079] Fault feature identification: The dynamic strategy matrix generator needs to identify the specific characteristics of faults in order to formulate appropriate handling solutions. Feature extraction: Extracting fault-related features from the collected data. For example, for video stuttering faults, features such as video frame interval, packet loss rate, and bandwidth usage are extracted. Feature classification: Classifying the extracted features to determine the type and severity of the fault. Faults can be classified into different levels based on factors such as the scope of impact and duration, such as high-priority, medium-priority, and low-priority faults. For example, faults affecting critical business operations (such as security monitoring) are usually classified as high-priority faults. Feature correlation: Analyzing the correlation between fault features to further clarify the root cause of the fault. For example, if video stuttering faults are found to be related to optical power fluctuations in the optical modem and Wi-Fi channel interference in the gateway, in-depth analysis can determine the main cause of the fault.

[0080] The processing solution generation process involves a dynamic policy matrix generator seeking solutions based on identified fault characteristics. **Preset Rule Base:** A preset rule base is established, defining corresponding processing solutions for different fault characteristics and types. For example, when a fault is detected in the optical modem port, the corresponding processing solution in the rule base might be port switching. **Reinforcement Learning Policy Engine:** Utilizing reinforcement learning algorithms, the processing solution is optimized through continuous trial and error and learning. After each fault handling, a corresponding reward or penalty is given based on the handling result, updating the policy matrix. For example, a positive reward is given when a processing solution successfully repairs the fault, and a negative reward is given otherwise. Through multiple iterations, the reinforcement learning policy engine can learn the optimal processing strategy. **Multimodal Decision Fusion:** Combining multiple decision-making methods, such as expert experience, historical data, and machine learning models, a more reasonable processing solution is generated by comprehensively considering various factors. For example, for complex cross-layer faults, the optimal processing solution is formulated by referring to expert experience and suggestions, combining historical fault data, and the prediction results of machine learning models.

[0081] In some embodiments, the fault mode library of this disclosure adopts an incremental update strategy for dynamic updates, uploading only the feature vectors of newly added fault samples, reducing communication overhead to at least <2KB / device, and dynamically updating the model, effectively balancing model timeliness and network load.

[0082] In some embodiments, the failure mode probability output by the federated learning model is used as the state input for reinforcement learning to dynamically adjust the priority of the repair strategy; this mechanism improves the accuracy of repair instructions.

[0083] This disclosure employs federated learning optimization, with each level of device uploading local feature vectors via an encrypted channel daily from 03:00 to 05:00; the cloud server aggregates and generates a global fault mode library, which is then distributed to the edge decision center (updated every 7 days).

[0084] In some embodiments, the core algorithm formula for the dynamic policy matrix generator capability iteration, and the Q-value update formula are as follows:

[0085] in, Indicates the current status (such as fault type, priority, device load). This indicates the currently executing action (such as switching the optical modem port or adjusting the gateway channel). This indicates an immediate reward (+10 for a successful repair, -5 for a failure). This represents the learning rate (0.1~0.3, controlling the weight of new and old experiences). This represents a discount factor (0.8~0.95, balancing immediate and long-term rewards).

[0086] Capability iteration and scenario adaptation logic calculation.

[0087] State space definition: =[Fault Level, Priority, Repair History, Network Load]

[0088] Motion space design: ∈{Optical modem system-level repair, gateway coordination repair, terminal local retry}

[0089] Reward function design:

[0090] By analyzing the feedback from different remediation strategies and the positive feedback from the federated learning model, the dynamic strategy matrix and case data are continuously optimized.

[0091] In some embodiments, the federated learning model disclosed herein breaks through the dimensional limitations of traditional single-layer detection, realizing cross-layer fault feature fusion analysis of the physical layer (optical modem layer), gateway layer (link layer), and application layer (terminal layer), and constructing a global fault mode library. A logical diagram is shown below. Figure 6 .

[0092] like Figure 7 As shown, the model iteration process is as follows: Encrypted feature aggregation mechanism: After each level of device extracts features locally, the gradient is encrypted using homomorphic encryption (such as the Paillier algorithm) to ensure that the original data does not leave the local area; Layered training strategy: Devices at each level train collaboratively in the same sample space but different feature spaces to solve the problem of cross-layer data heterogeneity; the optical modem focuses on physical layer features, the terminal focuses on application layer features, and the gateway acts as an intermediate layer to integrate the two types of features.

[0093] Dynamic model update: During periods of low load, the model is updated using historical data, uploading only the gradients of newly added fault samples, and performing model self-learning training.

[0094] The federated analysis model in the above embodiments is described in detail below, including the global fault analysis model deployed on the server side (cloud) and the edge fault analysis model deployed on the edge node (device side).

[0095] The logistic regression loss function for the edge fault analysis model is as follows:

[0096] The gradient is calculated as follows:

[0097] In the above formula, X represents the local feature matrix (such as optical modem optical power, terminal service flow features); y represents the fault label (1 = fault, 0 = normal); W represents the model weight.

[0098] The global fault analysis model uses the following formula for encrypted gradient aggregation:

[0099] In the above formula, Indicates the global learning rate; The gradient of the i-th device after encryption is represented; Decrypt() represents the homomorphic encryption decryption function (such as Paillier algorithm decryption); and N represents the number of devices participating in federated learning.

[0100] In smart home and healthcare scenarios, this disclosure utilizes the "data remains stationary, model moves" characteristic of federated learning to prevent the leakage of sensitive user data (such as videos and medical information), complying with privacy regulations and enhancing user trust in smart devices. In smart community and industrial IoT scenarios, the distributed autonomous operation and maintenance mechanism reduces manual intervention, lowering enterprise investment in manpower and hardware. The federated learning dynamic modeling and cross-layer collaborative repair technologies in the patent can become core selling points for enterprise products, helping to establish technological barriers in the smart home and IoT platform markets. Furthermore, the cross-layer diagnostics and privacy-preserving feature exchange technologies in this disclosure can provide a reference for the IoT industry to formulate autonomous operation and maintenance standards, promoting the standardized development of smart homes, industrial internet, and other fields.

[0101] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0102] Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0103] The following reference Figure 8 This describes the electronic device provided in the embodiments of this disclosure. Figure 8 The electronic device 800 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0104] Figure 8 This diagram illustrates the architecture of an electronic device 800 provided in an embodiment of the present invention. Figure 8 As shown, the electronic device 800 includes, but is not limited to, at least one processor 810 and at least one memory 820. The memory 820 is used to store instructions.

[0105] In some embodiments, memory 820 may include a readable medium in the form of volatile memory cells, such as random access memory (RAM) 8201 and / or cache 8202, and may further include read-only memory (ROM) 8203.

[0106] In some embodiments, the memory 820 may also include a program / utility 8204 having a set (at least one) program module 8205, such program module 8205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0107] In some embodiments, memory 820 may store an operating system. This operating system may be a real-time operating system (RTX), such as Linux, UNIX, Windows, or OS X.

[0108] In some embodiments, the memory 820 may also store data.

[0109] As an example, processor 810 can read data stored in memory 820, which may be stored at the same memory address as the instruction, or the data may be stored at a different memory address than the instruction.

[0110] Processor 810 is configured to invoke instructions stored in memory 820 to implement the steps described in the "Exemplary Methods" section above, according to various exemplary embodiments of this disclosure. For example, processor 810 can execute the steps of the above-described network fault handling method embodiments.

[0111] It should be noted that the processor 810 described above can be a general-purpose processor or a special-purpose processor. The processor 810 may include one or more processing cores, and the processor 810 executes various functional applications and data processing by running instructions.

[0112] In some embodiments, processor 810 may include a central processing unit (CPU) and / or a baseband processor.

[0113] In some embodiments, the processor 810 may determine an instruction based on the priority identifier and / or function category information carried in each control instruction.

[0114] In this disclosure, the processor 810 and memory 820 can be configured separately or integrated together. As an example, the processor 810 and memory 820 can be integrated on a single board or a system-on-chip (SOC).

[0115] like Figure 8 As shown, the electronic device 800 is presented in the form of a general-purpose computing device. The electronic device 800 may also include a bus 830.

[0116] Bus 830 can represent one or more of several types of bus structures, including a memory bus or memory controller, peripheral bus, graphics acceleration port, processor, or a local bus using any of the various bus structures.

[0117] Electronic device 800 can also communicate with one or more external devices 840 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 800, and / or with any device that enables electronic device 800 to communicate with one or more other computing devices (e.g., router, modem, etc.). Such communication can be performed through input / output (I / O) interface 850.

[0118] Furthermore, the electronic device 800 can also communicate with one or more networks (such as local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via the network adapter 860.

[0119] like Figure 8 As shown, the network adapter 860 communicates with other modules of the electronic device 800 via the bus 830.

[0120] It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 800, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0121] It is understood that the structures illustrated in the embodiments of this disclosure do not constitute a specific limitation on the electronic device 800. In other embodiments of this disclosure, the electronic device 800 may include... Figure 8 This may involve more or fewer components, or combining certain components, or splitting certain components, or different component arrangements. Figure 8 The components shown can be implemented in hardware, software, or a combination of both.

[0122] This disclosure also provides a computer-readable storage medium storing computer instructions thereon, which, when executed by a processor, implement the network fault handling method described in the above method embodiments.

[0123] In this disclosure, the computer-readable storage medium is one capable of sending, propagating, or transmitting computer instructions for use by or in connection with an instruction execution system, apparatus, or device. As an example, the computer-readable storage medium is a non-volatile storage medium.

[0124] In some embodiments, more specific examples of computer-readable storage media in this disclosure may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, USB flash drives, portable hard drives, or any suitable combination of the foregoing.

[0125] In this embodiment of the disclosure, the computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, wherein computer instructions (readable program code) are carried.

[0126] In some examples, computational instructions contained on a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0127] This disclosure also provides a computer program product storing instructions that, when executed by a computer, cause the computer to implement the network fault handling method described in the above-described method embodiments. These instructions may be program code. In specific implementations, the program code may be written using any combination of one or more programming languages. The program code may execute entirely on a user's computing device, partially on a user's device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0128] This disclosure also provides a chip including at least one processor and an interface; the interface is used to provide program instructions or data to at least one processor; the at least one processor is used to execute the program instructions to implement the network fault handling method described in the above method embodiments.

[0129] In some embodiments, the chip may further include a memory for storing program instructions and data, the memory being located within or outside the processor.

[0130] Those skilled in the art will understand that all or part of the steps of the above embodiments can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, which can be collectively referred to as "circuit", "module" or "system".

[0131] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein.

[0132] This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. A network fault handling method characterized by, include: The lightweight diagnostic engine deployed on each edge node acquires physical layer data, network layer data, and application layer data of each edge node. The physical layer data, the network layer data, and the application layer data are input into a global fault analysis model built based on federated learning to obtain global fault features. The global fault features are a unified feature representation that characterizes the fault correlation relationships across devices and across protocol stacks. Based on the global fault characteristics, combined with the current network load status, service priority and device computing power distribution, a fault handling strategy adapted to the current scenario is generated through a dynamic strategy matrix generator. The fault handling strategy is executed, and the cross-level fault analysis model and the dynamic strategy matrix generator are updated based on the execution result feedback.

2. The method of claim 1, wherein, After executing the fault handling strategy, the method further includes: By using the lightweight diagnostic engine deployed on each edge node, physical layer data, network layer data, and application layer data of each edge node are obtained again. Based on the re-acquired physical layer data, network layer data, and application layer data, it is determined whether the fault has been recovered after the fault handling strategy is executed.

3. The method of claim 2, wherein, The method further includes: If the fault is not resolved after executing the fault handling strategy, or if the fault handling strategy is not matched by the dynamic strategy matrix generator, the fault information is reported to the network management system.

4. The method of claim 3, wherein, The process of acquiring physical layer data, network layer data, and application layer data of each edge node through a lightweight diagnostic engine deployed at each edge node includes: acquiring the local feature matrix and fault label corresponding to each edge node sent by the lightweight diagnostic engine deployed at each edge node; wherein, the local feature matrix and fault label are obtained by the edge fault analysis model in the lightweight diagnostic engine processing the physical layer data, network layer data, and application layer data. The step of performing fault feature correlation analysis based on the physical layer data, the network layer data, and the application layer data to obtain global fault features includes: aggregating and generating the global fault features based on the local feature matrix and fault labels corresponding to each edge node through a global fault analysis model; The edge fault analysis model and the global fault analysis model are trained through federated learning, and encrypted gradient aggregation is used during the training process to protect data privacy.

5. The method of claim 4, wherein, After reporting the fault information to the network management system, the method further includes: After the fault is repaired manually or automatically, the fault information and its corresponding repair strategy are used as new samples to train the edge fault analysis model and the global fault analysis model, and the lightweight diagnostic engine deployed on each edge node is updated based on the training results.

6. The method of claim 1, wherein, The lightweight diagnostic engine is deployed in optical network units, gateway devices, and / or terminals.

7. The method of claim 1, wherein, Based on the global fault characteristics, and combined with the current network load status, service priority, and device computing power distribution, a fault handling strategy adapted to the current scenario is generated through a dynamic policy matrix generator, including: Based on the global fault feature, combined with the current network load state, service priority and device computing power distribution, the current state data is determined, including fault type, fault priority and device load; The current state data is input into the dynamic strategy matrix generator, and the current execution action is output as the fault processing strategy; Wherein, the dynamic strategy matrix generator is trained based on reinforcement learning algorithm, and its reward function gives positive or negative feedback according to whether the fault is successfully repaired.

8. The method of claim 1, wherein, The execution of the fault processing strategy includes: Through the resource coordination scheduler, the three-level resources of edge cloud are called to execute operations including cross-device computing power pooling, channel switching, service quality adjustment or link reconfiguration.

9. The method of claim 1, wherein, The method further includes: Through the protocol stack probe module, physical layer signal strength, transmission layer handshake delay and application layer service quality index are collected to build a full protocol stack running state digital twin, providing multi-dimensional feature input for the global fault analysis model.

10. An electronic device, comprising: Including: Memory for storing instructions; Processor for calling the instructions stored in the memory to realize the network fault processing method of any one of claims 1-9.

11. A computer program product, characterised in that, The computer program product stores instructions, which, when executed by a computer, cause the computer to implement the network fault processing method of any one of claims 1-9.

Images