A fault diagnosis method and system for an FTTR optical gateway based on large model inference

Abstract

This invention discloses a fault diagnosis method and system for FTTR optical gateways based on large-model inference, relating to the field of network communication technology. It acquires FTTR topology information, optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text of the FTTR optical gateway. Based on the FTTR topology information, it constructs an FTTR topology association structure and determines the node status of each faulty entity node based on the optical link information, optical gateway operation information, wireless access information, and service experience information, generating an FTTR fault association graph. This invention relies on a fault knowledge base to retrieve and match knowledge fragments and construct an enhanced retrieval context using upstream and downstream topology association information before feeding it into the large model. This constrains the inference boundary, suppresses fluctuations in diagnostic results, and the large model simultaneously outputs multiple candidate faults and corresponding diagnostic inference chains and dedicated verification actions. It completely retains the intermediate inference process, facilitating maintenance review and reducing the workload of subsequent corrections.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, specifically to a method and system for FTTR optical gateway fault diagnosis based on large model inference. Background Technology

[0002] FTTR, as a mainstream all-optical networking solution for homes, commercial buildings, hotels, and offices, covers the entire house / floor by using a main optical gateway paired with multiple slave optical gateways, indoor fiber optic cables, and wireless access units. It has advantages such as high transmission bandwidth, uniform wireless coverage, and strong multi-terminal concurrent support capabilities, and is now deployed on a large scale in commercial applications.

[0003] Current FTTR optical gateway fault diagnosis methods mostly adopt a modular, independent parsing processing mode for various types of fault information. For heterogeneous data from multiple sources, such as user natural language fault reports, historical work orders, gateway operation, optical links, wireless access, and service experience, they are usually disassembled and analyzed separately. This makes it difficult to completely connect fault correlation clues and affects the accuracy of fault location identification. In FTTR networks, there are clear upstream and downstream connection relationships and fault impact relationships between the main optical gateway, slave optical gateways, indoor fiber optic links, wireless access units, and terminals. Existing fault diagnosis methods usually make judgments based on single alarms, single performance indicators, or user fault reports, which makes it difficult to accurately distinguish between upstream root cause faults and downstream affected phenomena. At the same time, when using large models for fault diagnosis, most existing methods directly input the original gateway monitoring data, alarm data, or user fault report text into the large model and output the fault conclusion at once. Although it can utilize the semantic understanding and reasoning capabilities of large models, the reasoning input lacks constraints oriented towards the FTTR topology, the intermediate links in the reasoning are difficult to retain and trace, and the diagnostic output results are prone to fluctuations.

[0004] Furthermore, in existing operation and maintenance systems, active detection or retesting operations are mostly performed as independent troubleshooting actions, and are usually not linked with candidate fault causes generated by large models. It is also difficult to use real-time verification results to calculate the confidence of candidate fault causes. Therefore, when multiple candidate fault causes exist at the same time, existing methods are prone to the problem of determining the root cause of the fault based solely on semantic reasoning results or single detection results, which affects the accuracy, interpretability, and reliability of FTTR optical gateway fault diagnosis. To address this, a fault diagnosis method and system for FTTR optical gateways based on large model reasoning is proposed to solve the problems mentioned above. Summary of the Invention

[0005] To address the aforementioned technical issues, this paper provides a fault diagnosis method and system for FTTR optical gateways based on large-model inference. This solution overcomes the limitations of current FTTR optical gateway fault diagnosis methods described in the background. These methods typically employ a modular, independent parsing approach for processing various types of fault information. For heterogeneous data from multiple sources, such as user natural language fault reports, historical work orders, gateway operation data, optical link data, wireless access data, and service experience data, separate analysis is usually performed, making it difficult to fully connect fault correlation clues and affecting the accuracy of fault location identification. In FTTR networks, there are clear upstream and downstream connections and fault impact relationships between the main optical gateway, slave optical gateways, indoor fiber optic links, wireless access units, and terminals. Existing fault diagnosis methods usually rely solely on single alarms, single performance indicators, or user fault reports for judgment, making it difficult to accurately distinguish between upstream root cause faults and downstream affected phenomena. Meanwhile, when using large models for fault diagnosis, most existing methods directly input the original gateway monitoring data, alarm data, or user fault reports into the large model and output the fault conclusion at once. Although they can utilize the semantic understanding and reasoning capabilities of large models, the reasoning input lacks constraints oriented towards the FTTR topology, the intermediate links in the reasoning are difficult to retain and trace, and the diagnostic output results are prone to fluctuations. In addition, the active detection or retesting operations in existing operation and maintenance systems are mostly performed as independent troubleshooting actions, usually without forming a linkage with the candidate fault causes generated by the large model, and it is also difficult to use the real-time verification results to reverse the calculation of the confidence of the candidate fault causes. Therefore, when multiple candidate fault causes exist at the same time, existing methods are prone to the problem of determining the root cause of the fault based solely on the semantic reasoning results or a single detection result, which affects the accuracy, interpretability, and reliability of FTTR optical gateway fault diagnosis.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A fault diagnosis method for FTTR optical gateways based on large model inference includes:

[0008] Obtain FTTR topology information, optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text from the FTTR optical gateway;

[0009] FTTR topology association structure is constructed based on FTTR topology information, and the node status of each faulty entity node is determined based on optical link information, optical gateway operation information, wireless access information and service experience information, and an FTTR fault association diagram is generated.

[0010] Based on optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text, a fault symptom event sequence is generated;

[0011] Based on the fault symptom event sequence and FTTR fault association graph, a retrieval-enhanced diagnostic context for FTTR optical gateway fault diagnosis is constructed and input into a large model to generate a set of candidate fault causes, as well as a diagnostic reasoning chain and recommended verification actions corresponding to each candidate fault cause.

[0012] Active verification is performed based on the recommended verification action corresponding to each candidate fault cause, and the verification result corresponding to each candidate fault cause is obtained.

[0013] Calculate the confidence level of each candidate fault cause based on the verification results, fault symptom event sequence, diagnostic inference chain, user fault report text, and FTTR fault association diagram.

[0014] The root cause of the target fault is determined based on the confidence level of each candidate fault cause, and the fault diagnosis results of the FTTR optical gateway are output.

[0015] Furthermore, a fault diagnosis system for FTTR optical gateways based on large model reasoning is proposed to implement the fault diagnosis method for FTTR optical gateways based on large model reasoning as described above, including:

[0016] The data acquisition module is used to acquire FTTR topology information, optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text of the FTTR optical gateway;

[0017] The fault scenario modeling module is used to construct the FTTR topology association structure based on FTTR topology information, determine the node status of each fault entity node based on optical link information, optical gateway operation information, wireless access information and service experience information, generate the FTTR fault association diagram, and generate the fault symptom event sequence based on optical link information, optical gateway operation information, wireless access information, service experience information and user fault report text.

[0018] The intelligent reasoning module is used to construct a retrieval-enhanced diagnostic context based on the fault symptom event sequence and FTTR fault association graph, and input it into the large model to generate a set of candidate fault causes, as well as the diagnostic reasoning chain and recommended verification actions corresponding to each candidate fault cause;

[0019] The confidence assessment module is used to perform active verification based on the recommended verification action corresponding to each candidate fault cause to obtain the verification result, and to calculate the confidence of each candidate fault cause by combining the diagnostic inference chain, fault symptom event sequence, user fault report text and FTTR fault association graph.

[0020] The diagnostic output module is used to determine the root cause of the target fault based on the confidence level of each candidate fault cause and output the fault diagnosis results of the FTTR optical gateway.

[0021] The beneficial effects of this invention compared to the prior art are:

[0022] This solution constructs an FTTR fault correlation diagram that includes the main optical gateway, slave optical gateways, indoor fiber optic links, wireless access units, and terminals. This diagram unifies the physical connection relationships, logical management relationships, node status, and fault impact direction in the FTTR network, comprehensively depicting the upstream and downstream fault propagation logic of the FTTR network. Furthermore, this solution uniformly converts optical link information, optical gateway operation information, wireless access information, service experience information, and user fault reports into a fault symptom event sequence. This allows fault information from different sources and in different formats to be structurally correlated according to event occurrence time, abnormal object, abnormal type, and affected object. This transforms single-point anomaly judgment into correlation diagnosis based on time sequence and topological impact path, reducing the risk of confusion between upstream root cause faults and downstream affected phenomena.

[0023] This solution relies on the FTTR fault knowledge base to retrieve and match fault knowledge fragments. It then combines the upstream fault entity nodes, downstream fault entity nodes, and affected terminals of the abnormal object in the FTTR fault association graph to generate a topological association context. The fault symptom event sequence, fault knowledge fragments, and topological association context are combined into a retrieval-enhanced diagnostic context and input into the large model. As a result, the reasoning process of the large model no longer depends solely on the original monitoring data or user fault reports, but is constrained by the FTTR topological influence relationship, fault knowledge fragments, and time-series symptom events. This ensures that the candidate fault causes output by the large model can explain the order of anomaly occurrence, the topological location of the abnormal object, and the actual affected area, thereby reducing diagnostic fluctuations caused by unconstrained semantic reasoning.

[0024] In this solution, the large model does not directly output the final root cause of the fault. Instead, it outputs a set of candidate fault causes, along with the fault cause type, suspected fault location, supporting evidence, conflicting evidence, impact range, diagnostic reasoning chain, and recommended verification actions for each candidate fault cause. The recommended verification actions are generated based on the fault cause type and suspected fault location of the candidate fault cause and are used to trigger active verification operations, enabling the candidate fault causes to be verified through real-time network status. At the same time, the active verification results, fault symptom event sequences, user fault report text, and FTTR fault correlation graph are used together to calculate the confidence of the candidate fault causes. The credibility of the candidate fault causes is quantified from four dimensions: symptom matching, topology matching, verification support, and fault report matching. Through the joint calculation of the above four types of parameters, the root cause judgment can be avoided by relying solely on a single alarm, a single business experience indicator, or a single output result of the large model. Attached Figure Description

[0025] Figure 1 This is a flowchart of a fault diagnosis method for FTTR optical gateways based on large model inference proposed in this invention;

[0026] Figure 2 This is a flowchart illustrating the generation of the FTTR fault correlation diagram in this invention.

[0027] Figure 3 This is a flowchart illustrating the generation of fault symptom event sequences in this invention;

[0028] Figure 4 This is a flowchart illustrating the generation of the candidate fault cause set, diagnostic reasoning chain, and recommended verification actions in this invention.

[0029] Figure 5 This is a flowchart illustrating the generation of verification results in this invention;

[0030] Figure 6 This is a block diagram of a fault diagnosis system for an FTTR optical gateway based on large model inference proposed in this invention. Detailed Implementation

[0031] The following description is intended to disclose the invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art.

[0032] Reference Figures 1-5 As shown, a fault diagnosis method for FTTR optical gateways based on large model inference includes:

[0033] S1. Obtain the FTTR topology information, optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text of the FTTR optical gateway;

[0034] Specifically, the FTTR topology information includes the master optical gateway identifier, slave optical gateway identifier, master-slave optical gateway connection relationship, indoor fiber optic link number, slave optical gateway location, wireless access unit identifier, and terminal access location. The master optical gateway identifier is used to identify the master optical gateway device in the FTTR network. The slave optical gateway identifier is used to identify each slave optical gateway device connected to the master optical gateway. The master-slave optical gateway connection relationship is topology data that records the corresponding mapping relationship between the master optical gateway port and each slave optical gateway port, used to determine the physical connection path between the master optical gateway and each slave optical gateway. The indoor fiber optic link number is a unique link code assigned to each indoor fiber between the master optical gateway and the slave optical gateway, used to identify the corresponding indoor fiber optic link between the master optical gateway and the slave optical gateway. The slave optical gateway location is location description information that marks the deployment area of ​​each slave optical gateway, used to determine the room, area, or floor where the slave optical gateway is located. The wireless access unit identifier is used to identify the wireless access unit that provides wireless access services. The terminal access location records the location information of the corresponding node of the terminal device accessing the network, used to determine the slave optical gateway, wireless access unit, or physical location of the terminal.

[0035] Optical link information includes received optical power, optical port status, PON registration status, and optical link alarms. Received optical power is the received optical signal power value collected at the optical port side, used to determine whether there is abnormal attenuation, weak light, or fiber breakage in the optical link. Optical port status is the physical connection status and logical working status data of the optical network port, used to determine whether the optical port is in a normal connection and available state. PON registration status is the registration and online status information of the optical gateway on the passive optical network side, used to determine whether the optical gateway has completed the PON side registration normally. Optical link alarms are various alarm event data generated by optical link monitoring, used to determine whether there is fiber breakage, weak light, disconnection, or registration abnormality in the optical link.

[0036] The optical gateway's operating information includes CPU utilization, memory utilization, and DHCP allocation status. CPU utilization is the resource usage ratio of the optical gateway's processor, used to determine if there are any system resource anomalies such as excessive processor load. Memory utilization is the usage ratio of the optical gateway's running memory, used to determine if there are any system resource anomalies such as memory exhaustion or overflow. DHCP allocation status is the address allocation and terminal acquisition status information of the Dynamic Host Configuration Protocol, used to determine whether the terminal can obtain a network address normally from the optical gateway.

[0037] Wireless access information includes terminal access status, wireless signal strength, channel utilization, and wireless interference intensity. Terminal access status indicates whether the terminal has successfully accessed the wireless network. Wireless signal strength is the received signal strength indicator value collected by the terminal side, used to determine the wireless coverage quality of the terminal's location. Channel utilization is the proportion of time the current wireless channel is occupied, used to determine whether the current wireless channel is congested. Wireless interference intensity is the intensity data of co-channel and adjacent-channel interference signals in the wireless environment, used to determine whether there is interference in the surrounding wireless environment.

[0038] The service experience information includes connectivity results, latency, packet loss rate, and DNS resolution results. Connectivity results indicate whether the terminal service can access the network normally. Latency is the transmission time of data packets from the source to the destination, used to judge the service access response speed. Packet loss rate is the proportion of data packets lost during transmission to the total number of data packets, used to judge the service transmission stability. DNS resolution results indicate whether the domain name resolution is normal.

[0039] Furthermore, the user's fault report text includes the fault phenomenon, fault location, fault time, and affected services. The fault phenomenon is the text content describing the abnormal network behavior, such as: inability to access the Internet, slow network speed, no signal in a certain location, service lag, or offline from the optical gateway. The fault location is the text content describing the area where the fault occurred. The fault time is the information of the time when the fault occurred, as described by the user or recorded by the system. Affected services are the information of the type of network service that was affected, such as: Internet access, video, games, office work, or other network services.

[0040] S2. Construct an FTTR topology association structure based on the FTTR topology information, and determine the node status of each faulty entity node based on optical link information, optical gateway operation information, wireless access information, and service experience information, and generate an FTTR fault association diagram;

[0041] Furthermore, an FTTR topology association structure is constructed based on the FTTR topology information, and the node status of each faulty entity node is determined based on optical link information, optical gateway operation information, wireless access information, and service experience information, generating an FTTR fault association diagram, specifically including:

[0042] S21. Based on the FTTR topology information, extract the main optical gateway, slave optical gateway, indoor fiber optic link, wireless access unit and terminal as faulty entity nodes and establish connection edges between the faulty entity nodes.

[0043] Specifically, based on the main optical gateway identifier, slave optical gateway identifier, indoor fiber optic link number, wireless access unit identifier, and terminal access location, the corresponding main optical gateway, slave optical gateway, indoor fiber optic link, wireless access unit, and terminal are identified and designated as faulty entity nodes.

[0044] Furthermore, based on the master-slave optical gateway connection relationship, a connection edge is established between the master optical gateway and the corresponding slave optical gateway. Based on the correspondence between the indoor fiber optic link number and the master optical gateway and slave optical gateway, a series connection edge is established between the master optical gateway, the indoor fiber optic link, and the slave optical gateway. Based on the subordinate correspondence between the wireless access unit identifier and the slave optical gateway, a connection edge is established between the slave optical gateway and the corresponding wireless access unit. Based on the association between the terminal access location and the wireless access unit, a connection edge is established between the wireless access unit and the corresponding terminal. Based on the location of the slave optical gateway, a mapping association relationship is established between the slave optical gateway and its deployment location.

[0045] It should be noted that connection edges are used to indicate the physical connection relationship or fault propagation relationship between two faulty entity nodes. For example, the logical management association edge between the master optical gateway and the slave optical gateway is used to indicate the device ownership and management relationship between the master optical gateway and the slave optical gateway. The serial connection edge between the master optical gateway, the indoor fiber optic link and the slave optical gateway is used to indicate the physical fault propagation relationship of the master optical gateway failure or the indoor fiber optic link failure to the slave optical gateway. The connection edge between the indoor fiber optic link and the slave optical gateway is used to indicate that the attenuation or interruption of the indoor fiber optic link may affect the normal operation of the corresponding slave optical gateway. The connection edge between the wireless access unit and the terminal is used to indicate that the wireless access failure may affect the network use of the corresponding terminal.

[0046] S22. Determine the node status of each faulty entity node. The node status includes online status, abnormal performance status, and service impact status. The node status of the master optical gateway, slave optical gateway, and indoor fiber optic link also includes alarm status.

[0047] It should be noted that the node status of the main optical gateway, slave optical gateway, and indoor fiber optic link includes online status, alarm status, performance abnormal status, and service impact status. The node status of the wireless access unit and terminal also includes online status, performance abnormal status, and service impact status.

[0048] Furthermore, the normal operating range is determined by the threshold configuration table. The threshold configuration table is pre-configured and stored based on the FTTR equipment model parameters, operator operation and maintenance strategies, service quality requirements and historical operating baselines. The threshold configuration table includes at least the normal range of received optical power, the upper limit of CPU utilization, the upper limit of memory utilization, the lower limit of wireless signal strength, the upper limit of channel utilization, the upper limit of wireless interference intensity, the upper limit of latency, and the upper limit of packet loss rate.

[0049] In one implementation of this scheme, the normal range of received optical power is -27dBm to -8dBm, the upper limit of CPU utilization is 80%, the upper limit of memory utilization is 85%, the lower limit of wireless signal strength is -75dBm, the upper limit of channel utilization is 70%, the upper limit of wireless interference intensity is -80dBm, the upper limit of latency is 100ms, and the upper limit of packet loss rate is 1%. The above values ​​can be adjusted according to the FTTR equipment model, service level, and operator policy.

[0050] Specifically, for a faulty physical node that is either the primary or secondary optical gateway, its online status is determined as online when both the optical port status and PON registration status are available, and offline when either is unavailable. When there are alarms for fiber breakage, weak light, dropped connection, or registration anomalies, its alarm status is determined as alarm present. When there are no optical link alarms, its alarm status is determined as no alarm. When CPU or memory usage exceeds the normal operating range, or DHCP allocation is abnormal, its performance is determined as abnormal; otherwise, it is determined as normal. When a terminal associated with the faulty physical node experiences access anomalies, or the corresponding service experiences connectivity anomalies, latency anomalies, packet loss anomalies, or DNS resolution anomalies, the service impact status of the faulty physical node is determined as having service impact; otherwise, it is determined as having no service impact.

[0051] For faulty physical nodes that are indoor fiber optic links, when the optical port status is normal and the corresponding PON registration status of the secondary optical gateway is normal, its online status is determined to be connected. When the optical port status is abnormal or the corresponding PON registration status of the secondary optical gateway is abnormal, its online status is determined to be interrupted or connected abnormal. When there are alarms for fiber breakage, weak light, dropped connection, or registration abnormality, its alarm status is determined to be alarm present; otherwise, it is determined to be alarm-free. When the received optical power is not within the normal operating range, its performance abnormality status is determined to be abnormal. When the received optical power is within the normal operating range, its performance abnormality status is determined to be normal. When the corresponding secondary optical gateway is offline or connected abnormally, or when the terminal associated with the faulty physical node experiences connectivity abnormalities, latency abnormalities, packet loss abnormalities, or DNS resolution abnormalities, its service impact status is determined to be service impact present; otherwise, it is determined to be no service impact.

[0052] For faulty entity nodes that are wireless access units, when a terminal can normally access the wireless network through the wireless access unit, its online status is determined to be online. When none of the corresponding terminals can normally access the wireless network through the wireless access unit, its online status is determined to be access abnormal. When the wireless signal strength is lower than the normal operating range, the channel utilization is higher than the normal operating range, or the wireless interference strength is higher than the normal operating range, its performance abnormal status is determined to be abnormal; otherwise, it is determined to be normal. When the corresponding terminal experiences access abnormality, connectivity abnormality, latency abnormality, packet loss abnormality, or DNS resolution abnormality, its service impact status is determined to be affected; otherwise, it is determined to be unaffected.

[0053] For faulty entity nodes that are terminals, when the terminal access status is normal, its online status is determined to be online; when the terminal does not access or access fails, its online status is determined to be offline or access abnormal; when the connectivity result is abnormal, the latency exceeds the preset latency threshold, the packet loss rate exceeds the preset packet loss rate threshold, or the DNS resolution result is abnormal, its performance abnormal status is determined to be abnormal; otherwise, it is determined to be normal; when the terminal cannot access the Internet, the network speed is slow, the service is stuck, the DNS resolution fails, or other services are affected, its service impact status is determined to be affected; otherwise, it is determined to be unaffected.

[0054] Understandably, the online status indicates whether the faulty entity node is in a normal connection or access state, the alarm status indicates whether there is a corresponding valid alarm for the faulty entity node, the performance anomaly status indicates whether the corresponding operating indicators of the faulty entity node are within the normal operating range, and the service impact status indicates whether the anomaly of the faulty entity node has an impact on the terminal or service associated with it.

[0055] S23. Determine the influence direction of each connection edge. The influence direction is used to represent the influence relationship between the abnormality of the upstream faulty entity node and the downstream faulty entity node or terminal.

[0056] Specifically, when there is a connection between the primary optical gateway and the secondary optical gateway, the direction of influence is determined to be from the primary optical gateway to the secondary optical gateway; when there is a connection between the indoor fiber optic link and the secondary optical gateway, the direction of influence is determined to be from the indoor fiber optic link to the secondary optical gateway; when there is a connection between the secondary optical gateway and the wireless access unit, the direction of influence is determined to be from the secondary optical gateway to the wireless access unit; when there is a connection between the wireless access unit and the terminal, the direction of influence is determined to be from the wireless access unit to the terminal; and when there is a connection between the primary optical gateway and the indoor fiber optic link, the direction of influence is determined to be from the primary optical gateway to the indoor fiber optic link.

[0057] S24. Generate an FTTR fault association graph based on the faulty entity node, connecting edge, node status, and influence direction.

[0058] Specifically, the faulty entity node is treated as a graph node, the connecting edge is treated as a graph edge, the node status is treated as a graph node attribute, and the influence direction is treated as a graph edge attribute to generate an FTTR fault association graph.

[0059] It should be noted that the FTTR fault correlation diagram is used to describe the connection relationships and fault impact relationships between the master optical gateway, slave optical gateway, indoor fiber optic links, wireless access units and terminals in the FTTR network, so that subsequent fault diagnosis can be transformed from single-point anomaly judgment to correlation diagnosis based on connection relationships and impact range.

[0060] S3. Generate a sequence of fault symptom events based on optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text;

[0061] Furthermore, based on optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text, a fault symptom event sequence is generated, specifically including:

[0062] S31. Perform time alignment and anomaly detection on optical link information, optical gateway operation information, wireless access information, and service experience information;

[0063] Specifically, optical link information, optical gateway operation information, wireless access information, and service experience information are uniformly sorted according to the collection time, and time windows are constructed for time alignment. Within the same time window, anomaly detection is performed on received optical power, optical port status, PON registration status, optical link alarm, CPU utilization, memory utilization, DHCP allocation status, terminal access status, wireless signal strength, channel utilization, wireless interference intensity, connectivity results, latency, packet loss rate, and DNS resolution results.

[0064] For example, a 30-second time window is preset, dividing the time into continuous, non-overlapping intervals: 0~30s, 30~60s, 60~90s, and so on. If the optical power acquisition time for a certain optical link is 12s, the gateway CPU acquisition time is 25s, the wireless interference intensity acquisition time is 42s, and the terminal service packet loss detection time is 56s, then the first two indicators are included in the 0~30s time window for joint anomaly detection, and the latter two indicators are included in the 30~60s time window for joint anomaly detection. All synchronously collected indicators within the same window participate in the anomaly judgment, ensuring that various network anomalies generated in the same time period can be identified synchronously.

[0065] Furthermore, when the received optical power is lower than the normal operating range, the optical port status is abnormal, the PON registration status is abnormal, or there is an optical link alarm, it is determined to be an optical link abnormality. When the CPU utilization or memory utilization exceeds the normal operating range, or the DHCP allocation status is abnormal, it is determined to be a gateway operation abnormality. When the terminal access status is abnormal, the wireless signal strength is lower than the normal operating range, the channel utilization is higher than the normal operating range, or the wireless interference intensity is higher than the normal operating range, it is determined to be a wireless access abnormality. When the connectivity result is abnormal, the latency exceeds the normal operating range, the packet loss rate exceeds the normal operating range, or the DNS resolution result is abnormal, it is determined to be a service experience abnormality.

[0066] It should be noted that the normal operating range used for anomaly detection is read from the threshold configuration table. When the same indicator has multiple values ​​corresponding to different device models, different service levels, or different regions in the threshold configuration table, the corresponding normal operating range is selected according to the device model, service level, or region attribute to which the abnormal object belongs. For status-based indicators, the normal operating range is represented by a preset set of normal states, such as optical port status as normal, PON registration status as successful registration, DHCP allocation status as successful allocation, terminal access status as successful access, connectivity result as successful connectivity, and DNS resolution result as successful resolution. When the collected result does not belong to the corresponding set of normal states, the status-based indicator is determined to be abnormal.

[0067] S32. Convert optical link anomalies, gateway operation anomalies, wireless access anomalies, and service experience anomalies that occur within the same time window into fault symptom events. Each fault symptom event includes the event occurrence time, the abnormal object, the anomaly type, the anomaly index value, the anomaly duration, and the affected object.

[0068] Specifically, the event occurrence time is the time when the corresponding anomaly first appears; the anomaly object is the optical port, main optical gateway, secondary optical gateway, wireless access unit, terminal or service that has an anomaly; the anomaly type is optical link anomaly, gateway operation anomaly, wireless access anomaly or service experience anomaly; the anomaly indicator value is the indicator value that triggers anomaly detection; the anomaly duration is the duration from the occurrence of the anomaly to recovery or to the current detection time; and the affected objects are the secondary optical gateways, locations, terminals or services affected by the anomaly.

[0069] It should be noted that converting anomalies into fault symptom events can unify data from different sources and in different formats into structured events, which facilitates the input for subsequent large-scale model inference.

[0070] S33. Perform semantic parsing on user fault reports to extract fault location, fault symptoms, affected services, and fault time;

[0071] Specifically, the system performs word segmentation, keyword recognition, and semantic intent recognition on user-reported fault texts to extract the fault location, fault symptoms, affected services, and fault time from the user description.

[0072] For example, a user's fault report text is "Tonight, the video kept buffering when I watched it in my bedroom, and the internet speed was very slow after my phone was connected to WiFi";

[0073] First, the user's fault report text is segmented to obtain words or phrases such as "tonight", "bedroom", "watching videos", "constantly stuck", "phone", "connecting to WiFi" and "very slow network speed";

[0074] Then, through keyword recognition, "bedroom" was identified as the fault location keyword, "stuck" and "slow internet speed" were identified as fault symptoms keywords, "watching videos" was identified as the affected business keyword, and "tonight" was identified as the fault time keyword;

[0075] Then, through semantic intent recognition, it was determined that the user's fault report text expressed the fault intent of video service lag and abnormal wireless network speed in the bedroom area. Thus, the fault location was the bedroom, the fault symptoms were slow network speed and video lag, the affected service was video service, and the fault time was tonight.

[0076] It should be noted that when the user's fault report text does not explicitly include the fault time, the time when the system receives the user's fault report text will be taken as the fault time.

[0077] S34. Map the fault location to the optical gateway, wireless access unit or terminal node in the FTTR fault association diagram, and map the affected service to the terminal node carrying the service or as the service impact attribute of the corresponding terminal node.

[0078] Specifically, based on the fault location, the corresponding optical gateway, wireless access unit, or terminal is determined; based on the affected service, the terminal node carrying the service is determined; and the affected service is used as the service impact attribute of the corresponding terminal node. The fault location is mapped to the optical gateway, wireless access unit, or terminal node in the FTTR fault association diagram; the affected service is mapped to the terminal node carrying the service or used as the service impact attribute of the corresponding terminal node; the fault time extracted from the user's fault report text is used as the event occurrence time; the mapped fault entity node is used as the abnormal object; the fault phenomenon is used as the abnormal type; and the affected service is used as the affected object, generating a fault symptom event obtained from parsing the user's fault report text.

[0079] For example, when a user reports a fault and the message "Cannot access the Internet in the bedroom", the fault location is mapped to the corresponding optical gateway, wireless access unit, or terminal in the bedroom. When a user reports a fault and the message "Video stuttering" is included, the affected service is mapped to the service experience anomaly object on the corresponding terminal.

[0080] S35. Sort the fault symptom events according to their occurrence time to obtain the fault symptom event sequence.

[0081] Specifically, the fault symptom events obtained from the anomaly detection on the device side and the fault symptom events obtained from the parsing of user fault reports are sorted from earliest to latest according to the time of occurrence of the events to obtain the fault symptom event sequence.

[0082] It should be noted that the fault symptom event sequence is used to record the temporal order of fault occurrence, propagation, and impact, providing a structured diagnostic context for subsequent large-scale model inference.

[0083] S4. Based on the fault symptom event sequence and FTTR fault association graph, construct a retrieval-enhanced diagnostic context for FTTR optical gateway fault diagnosis and input it into the large model to generate a set of candidate fault causes and a diagnostic inference chain and recommended verification actions corresponding to each candidate fault cause.

[0084] Furthermore, based on the fault symptom event sequence and the FTTR fault correlation graph, a retrieval-enhanced diagnostic context for FTTR optical gateway fault diagnosis is constructed and input into the large model to generate a set of candidate fault causes, as well as a diagnostic inference chain and recommended verification actions corresponding to each candidate fault cause, specifically including:

[0085] S41. Obtain the FTTR fault knowledge base. Based on the abnormal objects, abnormal types, fault phenomena and affected services in the fault symptom event sequence, retrieve fault knowledge fragments from the FTTR fault knowledge base. The FTTR fault knowledge base includes optical link anomaly knowledge, master-slave optical gateway connection anomaly knowledge, wireless coverage anomaly knowledge, gateway system anomaly knowledge, service connectivity anomaly knowledge and fault handling rules.

[0086] Specifically, the FTTR fault knowledge base is a pre-built knowledge repository used to store fault knowledge required for FTTR optical gateway fault diagnosis. Among them, optical link anomaly knowledge includes fault causes corresponding to abnormal received optical power, optical port anomaly, PON registration anomaly, and optical link alarm; master-slave optical gateway connection anomaly knowledge includes fault causes corresponding to connection anomalies between the master and slave optical gateways; wireless coverage anomaly knowledge includes fault causes corresponding to weak wireless signal, channel congestion, and wireless interference; gateway system anomaly knowledge includes fault causes corresponding to abnormal CPU utilization, abnormal memory utilization, and abnormal DHCP allocation; service connectivity anomaly knowledge includes fault causes corresponding to connectivity anomalies, latency anomalies, packet loss anomalies, and DNS resolution anomalies; and fault handling rules are used to describe the handling actions corresponding to different fault causes.

[0087] Furthermore, based on the abnormal objects and abnormal types in the fault symptom event sequence, as well as the fault phenomena and affected services in the user's fault report text, retrieval information for the current fault is formed. The retrieval information is then matched with the fault types, fault objects, abnormal indicators, fault phenomena, and handling rules pre-stored in the FTTR fault knowledge base to obtain fault knowledge fragments related to the current fault.

[0088] For example, when the anomaly type is optical link anomaly and the fault phenomenon is offline from the optical gateway, match fault knowledge fragments related to optical power anomaly, PON registration anomaly, fiber breakage, or weak light.

[0089] S42. Extract the upstream fault entity nodes, downstream fault entity nodes, and affected terminals related to the abnormal object from the FTTR fault association graph, and generate the topology association context;

[0090] Specifically, based on the abnormal object in the fault symptom event, the fault entity node corresponding to the abnormal object is determined in the FTTR fault association diagram, and the fault entity node is taken as the current abnormal node. According to the influence direction of the connection edge, the fault entity node is traced upstream from the current abnormal node to obtain the main optical gateway, indoor fiber optic link, slave optical gateway or other upstream fault entity nodes that may cause the current abnormality. At the same time, the fault entity node is extended downstream from the current abnormal node to obtain the slave optical gateway, wireless access unit, terminal and service object that may be affected by the abnormality.

[0091] When tracing upstream from the current abnormal node, the search proceeds level by level in the opposite direction of the impact, starting from the current abnormal node, until the main optical gateway node is reached or no upstream connection edge exists. To avoid irrelevant nodes entering the topology association context, only upstream faulty entity nodes located on the same main-slave optical gateway connection path, the same indoor fiber optic link, or the same wireless access path as the current abnormal node are retained. When extending downstream from the current abnormal node, the search proceeds level by level in the impact direction, starting from the current abnormal node, until the terminal node is reached or no downstream connection edge exists. If the downstream node includes a terminal, the affected service object corresponding to that terminal is further extracted.

[0092] Furthermore, the current abnormal node, upstream faulty entity node, downstream faulty entity node, affected terminal, and the connection edges, influence directions, and node states between the above nodes are extracted and combined to generate a topology association context.

[0093] It should be noted that the topology association context is used to describe the topological location of the abnormal object in the FTTR network, the possible upstream causes, the downstream impact range, and the abnormal propagation path, so that the large model can combine the FTTR topology relationship to determine whether the candidate fault causes can explain the actual affected optical gateways, locations, terminals, and services.

[0094] S43. Combine the fault symptom event sequence, fault knowledge fragments, and topological association context into a retrieval-enhanced diagnostic context and input it into a large model to generate a set of candidate fault causes. Each candidate fault cause includes the fault cause type, suspected fault location, supporting evidence, conflicting evidence, scope of impact, and recommended verification actions.

[0095] Specifically, the enhanced diagnostic context for retrieval includes fault symptom event sequences, fault knowledge fragments, and topological association context. Fault symptom event sequences are used to provide real-time abnormal behavior of the current fault, fault knowledge fragments are used to provide the correspondence between fault types and abnormal phenomena, and topological association context is used to provide the upstream nodes, downstream nodes, and scope of influence of the abnormal object in the FTTR fault association graph.

[0096] Furthermore, the retrieved enhanced diagnostic context is input into the large model, enabling the large model to combine the anomaly occurrence time, anomaly object, anomaly type, and affected objects in the fault symptom event sequence, the correspondence between fault causes and anomalies in the fault knowledge fragment, and the upstream nodes, downstream nodes, and direction of influence in the topology association context to infer the correlation between optical link anomalies, master-slave optical gateway connection anomalies, wireless access anomalies, gateway system anomalies, and service experience anomalies.

[0097] Specifically, the large model determines the sequential relationship between different anomalies based on the time of anomaly occurrence, determines whether anomalies are located in the same impact path based on the anomaly object and the FTTR fault association diagram, determines the possible fault cause type corresponding to the anomaly phenomenon based on fault knowledge fragments, and determines whether the candidate fault causes can explain the actual impact range based on the affected objects, thereby generating a set of candidate fault causes.

[0098] The large model first determines the fault cause type based on the anomaly type in the fault symptom events. For example, when the fault symptom events include abnormal received optical power, abnormal PON registration status, or optical link alarm, the fault cause type of the corresponding candidate fault cause is determined to be optical link anomaly. When the fault symptom events include abnormal wireless signal strength, abnormal channel utilization, or abnormal wireless interference strength, the fault cause type of the corresponding candidate fault cause is determined to be wireless access anomaly.

[0099] Then, the large model determines the suspected fault location based on the position of the abnormal object in the FTTR fault association diagram. When the abnormal object is itself a main optical gateway, a secondary optical gateway, an indoor fiber optic link, or a wireless access unit, the abnormal object is taken as the suspected fault location. When the abnormal object is a terminal or service object, it is traced upstream along the influence direction of the FTTR fault association diagram, and the upstream fault entity node that can explain the abnormality of the terminal or service is taken as the suspected fault location.

[0100] Among them, the upstream faulty entity node that can explain the terminal or service abnormality refers to the upstream node that meets the following conditions simultaneously:

[0101] There is a path connecting the upstream node and the abnormal object along the direction of influence;

[0102] The upstream node's node status or corresponding fault symptom event contains an anomaly consistent with the candidate fault cause type;

[0103] The downstream impact range formed by the upstream node along the direction of impact includes the actual affected terminals or services.

[0104] Furthermore, the time of the abnormal event corresponding to the upstream node is no later than the time of the abnormal event of the terminal or business.

[0105] It should be noted that if there are multiple upstream nodes that meet the conditions, they will be output as suspected fault locations for different candidate fault causes.

[0106] Subsequently, the large model writes the fault symptom events, fault knowledge fragments, and topological relationships consistent with the candidate fault cause into supporting evidence. Consistency with the candidate fault cause means that the anomaly type, anomaly object, anomaly index value, or affected object in the fault symptom event can be explained by the candidate fault cause. The large model writes the fault symptom events that are inconsistent with the candidate fault cause or cannot be explained by the candidate fault cause into conflict evidence. For example, if a candidate fault cause is a wireless access anomaly, but the fault symptom events also contain a PON registration anomaly or an optical link alarm, the PON registration anomaly or optical link alarm will be used as conflict evidence.

[0107] Finally, starting from the suspected fault location, the large model searches downstream along the influence direction of the FTTR fault association diagram, determining the scope of influence from optical gateways, locations, wireless access units, terminals, and service objects. The large model then selects the corresponding recommended verification actions based on the fault cause type. For example, when the fault cause type is optical link anomaly, it recommends retesting received optical power, rechecking PON registration status, and rechecking optical link alarms; when the fault cause type is wireless access anomaly, it recommends rechecking wireless signal strength, detecting channel utilization, and detecting wireless interference strength; and when the fault cause type is gateway system anomaly, it recommends rechecking CPU utilization, rechecking memory utilization, and rechecking DHCP allocation status.

[0108] The fault cause type is used to describe whether the candidate fault cause belongs to optical link anomaly, master-slave optical gateway connection anomaly, wireless access anomaly, gateway system anomaly, or service experience anomaly; the suspected fault location is used to describe the master optical gateway, slave optical gateway, indoor fiber optic link, wireless access unit, or terminal corresponding to the candidate fault cause; supporting evidence is used to describe the fault symptom events, fault knowledge fragments, or topology relationships that support the candidate fault cause; conflicting evidence is used to describe the fault symptom events that are inconsistent with or not completely consistent with the candidate fault cause; the scope of impact is used to describe the slave optical gateways, locations, terminals, and services that the candidate fault cause may affect; and the recommended verification action is used to describe the active verification tasks that need to be performed.

[0109] It should be noted that the large model does not directly output the final root cause of the failure in this step. Instead, it outputs a set of candidate failure causes, supporting evidence, conflicting evidence, and recommended verification actions, so that the target root cause of the failure can be determined later through active verification and confidence calculation.

[0110] Furthermore, the large model in this embodiment is a pre-deployed generative language model obtained through interface calls. The large model includes an input encoding layer, a semantic understanding layer, a contextual reasoning layer, and a structured output layer. The input encoding layer is used to receive the retrieved enhanced diagnostic context and convert it into a model input representation. The semantic understanding layer is used to identify abnormal objects, abnormal types, fault phenomena, and business impacts. The contextual reasoning layer is used to perform causal association reasoning based on fault knowledge fragments and topological association context. The structured output layer is used to generate a set of candidate fault causes, supporting evidence, conflicting evidence, scope of impact, and recommended verification actions according to a preset output format. The large model can be obtained through local private deployment or by calling the deployed large model service through the operator's operation and maintenance platform. Before use, the FTTR fault knowledge base, output field format, and prompt template for prohibiting the direct output of the final root cause are written into the model call configuration to constrain its output range.

[0111] S44. Generate the corresponding diagnostic reasoning chain based on the supporting evidence, conflicting evidence, and connection relationships in the FTTR fault association diagram for each candidate fault cause.

[0112] Specifically, the diagnostic reasoning chain includes the reasoning process from fault symptom events to suspected fault locations, from suspected fault locations to affected objects, and from candidate fault causes to recommended verification actions.

[0113] Furthermore, when the supporting evidence is consistent with the connection relationship in the FTTR fault association diagram, the corresponding relationship is written into the diagnostic inference chain; when there is conflicting evidence, the conflicting evidence and its corresponding abnormal object are written into the diagnostic inference chain.

[0114] For example, when abnormal received optical power, abnormal PON registration status, and the corresponding offline slave optical gateway occur simultaneously, and the FTTR fault correlation diagram shows that the slave optical gateway is located downstream of the corresponding indoor fiber optic link, the diagnostic inference chain includes the inference process of "abnormal received optical power points to an abnormal optical link, the abnormal optical link affects the corresponding slave optical gateway, and the abnormal slave optical gateway affects its downstream terminals and services".

[0115] S5. Perform active verification based on the recommended verification action corresponding to each candidate fault cause, and obtain the verification result corresponding to each candidate fault cause;

[0116] Furthermore, active verification is performed based on the recommended verification action corresponding to each candidate fault cause to obtain the verification result corresponding to each candidate fault cause, specifically including:

[0117] S51. When the candidate fault cause is optical link abnormality, perform received optical power retest, PON registration status recheck and optical link alarm recheck;

[0118] Specifically, when performing a received optical power retest, the received optical power value of the optical port or indoor fiber optic link corresponding to the candidate fault cause is re-collected, and the re-collected received optical power value is compared with the corresponding normal operating range to determine whether the optical link has a persistent weak light or abnormal optical power. When performing a PON registration status recheck, the PON registration status of the optical gateway is re-queried to determine whether the optical gateway can register normally. When performing an optical link alarm recheck, the alarm information related to the optical link is re-queried to determine whether there are alarms such as fiber breakage, weak light, dropped connection or registration abnormality.

[0119] S52. When the candidate fault cause is an abnormal connection between the master and slave optical gateways, execute the online status query of the slave optical gateway, the connection status query of the master and slave optical gateways, and the status query of the indoor fiber optic link.

[0120] Specifically, when performing a query on the online status of a secondary optical gateway, the system checks whether the secondary optical gateway corresponding to the candidate fault cause is online, offline, or disconnected to determine if the secondary optical gateway is online. When performing a query on the connection status of a primary and secondary optical gateway, the system checks the connection relationship, connection status, or management status between the primary optical gateway and the corresponding secondary optical gateway to determine if the connection between the primary and secondary optical gateways is normal. When performing a query on the status of an indoor fiber optic link, the system checks the optical port status, received optical power, or link alarm information corresponding to the indoor fiber optic link between the primary and secondary optical gateways to determine if the indoor fiber optic link is abnormal.

[0121] S53. When the candidate fault cause is a wireless access anomaly, perform wireless signal strength review, channel utilization detection, and wireless interference strength detection.

[0122] Specifically, when performing a wireless signal strength review, the wireless signal strength of the terminal, wireless access unit, or fault location corresponding to the candidate fault cause is re-collected, and the re-collected wireless signal strength is compared with the corresponding normal operating range to determine whether there is insufficient wireless coverage at the terminal's location. When performing a channel utilization detection, the current channel utilization of the wireless access unit corresponding to the candidate fault location is queried, and the channel utilization is compared with the corresponding normal operating range to determine whether the current wireless channel is congested. When performing a wireless interference strength detection, the wireless interference strength of the wireless access unit corresponding to the candidate fault location is collected or queried, and the wireless interference strength is compared with the corresponding normal operating range to determine whether there is interference in the wireless environment.

[0123] S54. When the candidate fault cause is a gateway system abnormality, perform CPU utilization review, memory utilization review, and DHCP allocation status review;

[0124] Specifically, when performing a CPU utilization review, the CPU utilization of the primary or secondary optical gateway corresponding to the candidate fault cause is re-collected, and the re-collected CPU utilization is compared with the corresponding normal operating range to determine whether the optical gateway has any abnormal processing resources. When performing a memory utilization review, the memory utilization of the primary or secondary optical gateway corresponding to the candidate fault cause is re-collected, and the re-collected memory utilization is compared with the corresponding normal operating range to determine whether the optical gateway has any abnormal memory resources. When performing a DHCP allocation status review, the DHCP service status, address pool status, or terminal address allocation result of the optical gateway corresponding to the candidate fault cause is queried to determine whether the optical gateway can normally allocate network addresses to the terminal.

[0125] S55. When the candidate fault cause is an abnormal business experience, perform connectivity testing, latency testing, packet loss rate testing, and DNS resolution testing;

[0126] Specifically, during connectivity testing, network connectivity probes are initiated from the terminal or business object corresponding to the candidate fault cause to determine whether the terminal can access the network normally. During latency testing, access latency probes are performed on the terminal or business object corresponding to the candidate fault cause, and the obtained latency is compared with the corresponding normal operating range to determine whether the business access latency is abnormal. During packet loss testing, packet loss probes are performed on the terminal or business object corresponding to the candidate fault cause, and the obtained packet loss rate is compared with the corresponding normal operating range to determine whether the business transmission is stable. During DNS resolution testing, domain name resolution requests are initiated on the terminal or business object corresponding to the candidate fault cause to determine whether the domain name resolution is normal.

[0127] S56. Based on the results of the active verification, obtain the verification results corresponding to each candidate fault cause.

[0128] Specifically, the execution results of the active verification task corresponding to each candidate fault cause are summarized to obtain the verification results, which include verification supported items, verification unsupported items, and verification exception objects.

[0129] It should be noted that active verification is used to verify whether the candidate fault causes generated by the large model are consistent with the real-time network state.

[0130] S6. Calculate the confidence level of each candidate fault cause based on the verification results, fault symptom event sequence, diagnostic inference chain, user fault report text, and FTTR fault association diagram corresponding to each candidate fault cause;

[0131] Furthermore, based on the verification results, fault symptom event sequence, diagnostic inference chain, user fault report text, and FTTR fault correlation graph corresponding to each candidate fault cause, the confidence level of each candidate fault cause is calculated, specifically including:

[0132] S61. Calculate the degree of matching between candidate fault causes and abnormal events in the fault symptom event sequence, and calculate symptom matching parameters based on the degree of matching between candidate fault causes and abnormal events in the fault symptom event sequence;

[0133] Specifically, the kth candidate cause of failure is denoted as The number of fault symptom events in the fault symptom event sequence is denoted as... This will be related to the candidate fault causes. The number of matched fault symptom events is denoted as Then the symptom matching parameters of the k-th candidate fault cause for:

[0134]

[0135] Among them, the fault symptom event that matches the candidate fault cause refers to the fault symptom event whose abnormality type, abnormal object, or abnormal indicator value can support the candidate fault cause.

[0136] It should be noted that the larger the symptom matching parameter, the more consistent the candidate fault cause is with the abnormal events in the current fault symptom event sequence.

[0137] S62. Calculate the degree of matching between the suspected fault location corresponding to the candidate fault cause and the affected fault entity node in the FTTR fault association diagram. Based on the degree of matching between the suspected fault location corresponding to the candidate fault cause and the affected fault entity node in the FTTR fault association diagram, calculate the topology matching parameters.

[0138] Specifically, the suspected fault location corresponding to the k-th candidate fault cause is denoted as... Based on the FTTR fault correlation diagram, the suspected fault location was determined. The set of faulty entity nodes that can be affected downstream, denoted as Let B be the set of fault entity nodes actually affected in the fault symptom event sequence and user fault report text. The number of faulty entity nodes in the intersection with B is denoted as The number of faulty entity nodes in B is denoted as Then the topology matching parameters of the k-th candidate fault cause for:

[0139]

[0140] It should be noted that the larger the topology matching parameter, the more the suspected fault location corresponding to the candidate fault cause can explain the actual affected faulty entity node.

[0141] S63. Calculate the degree of support of the active verification results for the candidate fault causes, and calculate the verification support parameters based on the degree of support of the active verification results for the candidate fault causes;

[0142] Specifically, the number of active verification items corresponding to the k-th candidate fault cause is denoted as . The number of verification support items that support the candidate fault cause is denoted as Then the verification support parameters for the k-th candidate fault cause for:

[0143]

[0144] It should be noted that the larger the verification support parameter, the more the active verification result supports the candidate fault cause.

[0145] S64. Calculate the degree of matching between the candidate fault cause and the fault location, fault phenomenon and affected services in the user's fault report text. Calculate the fault reporting matching parameters based on the degree of matching between the candidate fault cause and the user's fault report text.

[0146] Specifically, the location matching result is recorded as The phenomenon matching results are recorded as Record the business matching results as When the suspected fault location corresponding to the candidate fault cause matches the fault location in the user's fault report text, Take 1, otherwise A value of 0 is used when the fault cause type corresponding to the candidate fault cause matches the fault phenomenon in the user's fault report text. Take 1, otherwise The value is 0 when the scope of impact corresponding to the candidate fault cause includes the affected services mentioned in the user's fault report text. Take 1, otherwise Take 0.

[0147] Furthermore, the fault matching parameters for the k-th candidate fault cause. for:

[0148]

[0149] It should be noted that the larger the fault matching parameter, the more consistent the candidate fault cause is with the fault perceived by the user.

[0150] S65. Calculate the confidence level of candidate fault causes based on symptom matching parameters, topology matching parameters, verification support parameters, and fault reporting matching parameters.

[0151] Specifically, the confidence level of the k-th candidate cause of failure. for:

[0152]

[0153] in, The symptom matching parameters are for the k-th candidate cause of failure. For the topology matching parameters of the k-th candidate fault cause, For the verification support parameters of the k-th candidate fault cause, The fault reporting matching parameters are for the k-th candidate fault cause.

[0154] It should be noted that the values ​​of the symptom matching parameter, topology matching parameter, verification support parameter, and fault reporting matching parameter are all in the range of 0 to 1. Therefore, the confidence of the candidate fault cause is in the range of 0 to 1. The higher the confidence of the candidate fault cause, the higher the comprehensive support of the candidate fault cause in the four aspects of equipment-side anomaly, topology influence, active verification, and user fault reporting.

[0155] S7. Determine the root cause of the target fault based on the confidence level of each candidate fault cause, and output the FTTR optical gateway fault diagnosis results.

[0156] Furthermore, based on the confidence level of each candidate fault cause, the target fault root cause is determined, and the FTTR optical gateway fault diagnosis results are output, specifically including:

[0157] S71. Sort the candidate fault causes according to their confidence level from high to low to obtain the fault root cause ranking result;

[0158] Specifically, all candidate causes of failure are ranked according to their confidence level. Sort the results from highest to lowest to obtain the root cause ranking of the faults.

[0159] S72. When the confidence level of the candidate fault cause with the highest confidence level is greater than the sum of the confidence levels of all other candidate fault causes, the candidate fault cause with the highest confidence level is determined as the target fault root cause;

[0160] Specifically, the candidate cause of failure with the highest confidence level is denoted as... Let its confidence level be denoted as , will be removed The sum of the confidence scores of the remaining candidate causes of failure is denoted as ;

[0161] when > When, explain It has significant advantages over other candidate causes of failure. The root cause of the target failure has been identified.

[0162] S73. When the confidence of the candidate fault cause with the highest confidence is less than or equal to the sum of the confidence of all other candidate fault causes, all candidate fault causes are independently sorted according to the symptom matching parameter, topology matching parameter, verification support parameter, and fault reporting matching parameter, respectively.

[0163] Specifically, when ≤ This indicates that there is still a competing relationship among multiple candidate fault causes, therefore, they are matched according to the symptom matching parameters. Topology matching parameters Verification of supported parameters Matching parameters with fault reports All candidate fault causes are independently sorted from highest to lowest, resulting in a sorting result with four parameters.

[0164] S74. Determine whether the order of the four parameters of the candidate fault cause with the highest confidence is the first among the candidate fault causes. If they are all first, then determine the candidate fault cause with the highest confidence as the target fault root cause. If they are not all first, output the diagnosis result to be manually reviewed, and send the fault root cause ranking result, diagnosis reasoning chain and verification result to the operation and maintenance end.

[0165] Specifically, if If it ranks first in all four categories—symptom matching parameter sorting, topology matching parameter sorting, verification support parameter sorting, and fault reporting matching parameter sorting—it means... Although it did not meet the criteria for significant advantage, it demonstrated optimal performance across four dimensions: device-side anomalies, topology impact, proactive verification, and user fault reporting. Therefore, it will be... The root cause of the target failure has been identified.

[0166] Furthermore, if If not all four parameters are ranked first, it indicates that different candidate fault causes have dispersed advantages across different evaluation dimensions. Automatically determining the root cause of the target fault carries the risk of misjudgment. Therefore, a manual review and diagnosis result is output, and the fault root cause ranking result, diagnosis reasoning chain, and verification result are sent to the operation and maintenance end.

[0167] S75. If the root cause of the target fault is determined, the affected optical gateways, locations, terminals and services shall be determined based on the suspected fault location corresponding to the root cause of the target fault and the FTTR fault association diagram.

[0168] Specifically, based on the suspected fault location corresponding to the root cause of the target fault, the downstream fault entity node is determined along the influence direction of the connection edge in the FTTR fault association graph, and the affected optical gateway, fault location, terminal and service are determined based on the downstream fault entity node.

[0169] For example, when the root cause of the target fault is the main optical gateway malfunction, the affected secondary optical gateways and terminals are determined according to the FTTR fault correlation diagram. When the root cause of the target fault is the indoor fiber optic link malfunction, the corresponding secondary optical gateway, fault location, and terminal are determined. When the root cause of the target fault is the wireless access malfunction, the terminals and services under the corresponding wireless access unit are determined. When the root cause of the target fault is the service experience malfunction, the affected services and corresponding terminals are determined.

[0170] S76. Generate a handling plan based on the root cause of the target fault and the fault handling rules. The handling plan includes remotely restarting the optical gateway, restoring the gateway configuration, adjusting the wireless channel, optimizing the wireless transmission parameters, reallocating terminal access, retesting the optical link, prompting the user to check the indoor fiber optic connection, and generating on-site dispatch suggestions.

[0171] Specifically, when the root cause of the target fault is a gateway system malfunction, a solution is generated to remotely restart the optical gateway, restore the gateway configuration, or recheck the DHCP allocation status. When the root cause of the target fault is a wireless access malfunction, a solution is generated to adjust the wireless channel, optimize the wireless transmission parameters, or reallocate terminal access. When the root cause of the target fault is an optical link malfunction or a master-slave optical gateway connection malfunction, a solution is generated to retest the optical link, prompt the user to check the indoor fiber optic connection, or generate on-site dispatch suggestions. When the root cause of the target fault is a service experience malfunction, a solution is generated to retest connectivity, retest latency, retest packet loss rate, or recheck DNS resolution.

[0172] It should be noted that the S7 target fault root cause determination method can automatically output the target fault root cause when the confidence of the fault cause is significantly superior. When multiple candidate fault causes are highly competitive, they are further reviewed by independent sorting of four types of parameters. If the conditions are still not met, the manual review result is output, thereby improving the reliability of FTTR optical gateway fault diagnosis.

[0173] Reference Figure 6 As shown, a fault diagnosis system for FTTR optical gateways based on large model reasoning is proposed to implement the fault diagnosis method for FTTR optical gateways based on large model reasoning as described above. The system is characterized by including a data acquisition module, a fault scenario modeling module, an intelligent reasoning module, a confidence assessment module, and a diagnostic output module.

[0174] The data acquisition module is used to acquire FTTR topology information, optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text of the FTTR optical gateway.

[0175] Specifically, the FTTR topology information acquired by the data acquisition module is used to determine the connection relationship between the main optical gateway, the secondary optical gateway, the indoor fiber optic link, the wireless access unit, and the terminal. The optical link information is used to reflect the optical port, received optical power, PON registration status, and optical link alarm status. The optical gateway operation information is used to reflect the system operation status of the main optical gateway or the secondary optical gateway. The wireless access information is used to reflect the terminal access, wireless coverage, channel occupancy, and wireless interference. The service experience information is used to reflect the connectivity, latency, packet loss, and DNS resolution during the terminal service access process. The user fault report text is used to reflect the fault location, fault phenomenon, fault time, and affected services perceived by the user.

[0176] The fault scenario modeling module is used to construct the FTTR topology association structure based on the FTTR topology information, determine the node status of each fault entity node based on optical link information, optical gateway operation information, wireless access information and service experience information, generate the FTTR fault association diagram, and generate the fault symptom event sequence based on optical link information, optical gateway operation information, wireless access information, service experience information and user fault report text.

[0177] Specifically, the fault scenario modeling module treats the main optical gateway, slave optical gateway, indoor fiber optic link, wireless access unit, and terminal as fault entity nodes. It establishes connection edges between fault entity nodes based on the connection relationship between the main and slave optical gateways, the indoor fiber optic link number, the wireless access unit identifier, and the terminal access location. It configures the node status of the fault entity nodes and the influence direction of the connection edges to generate an FTTR fault association graph. The fault scenario modeling module also performs time alignment and anomaly detection on optical link information, optical gateway operation information, wireless access information, and service experience information. Combined with the parsing results of user fault report texts, it converts the detected anomalies into fault symptom events and generates a fault symptom event sequence according to the event occurrence time.

[0178] The intelligent reasoning module is used to construct a retrieval-enhanced diagnostic context based on the fault symptom event sequence and the FTTR fault association graph, and input the large model to generate a set of candidate fault causes, as well as the diagnostic reasoning chain and recommended verification actions corresponding to each candidate fault cause.

[0179] Specifically, the intelligent reasoning module retrieves fault knowledge fragments related to the current fault from the FTTR fault knowledge base based on the abnormal object, abnormal type, fault phenomenon, and affected services in the fault symptom event sequence. Based on the position of the abnormal object in the FTTR fault association graph, it extracts the upstream fault entity node, downstream fault entity node, and affected terminal of the abnormal object to generate a topological association context. Then, it combines the fault symptom event sequence, fault knowledge fragments, and topological association context into a retrieval-enhanced diagnostic context and inputs it into the large model. The large model then combines the anomaly occurrence time, abnormal object, abnormal type, fault knowledge fragments, and topological influence relationship to generate a set of candidate fault causes, as well as the fault cause type, suspected fault location, supporting evidence, conflicting evidence, scope of impact, diagnostic reasoning chain, and recommended verification actions for each candidate fault cause.

[0180] The confidence assessment module is used to perform active verification based on the recommended verification action corresponding to each candidate fault cause to obtain the verification result, and to calculate the confidence of each candidate fault cause by combining the diagnostic inference chain, fault symptom event sequence, user fault report text and FTTR fault association graph.

[0181] Specifically, the confidence assessment module determines the corresponding active verification items based on the fault cause type of the candidate fault causes, and performs one or more of the following: received optical power retest, PON registration status recheck, optical link alarm recheck, online status query of the optical gateway, connection status query of the master and slave optical gateways, indoor fiber optic link status query, wireless signal strength recheck, channel utilization detection, wireless interference strength detection, CPU utilization recheck, memory utilization recheck, DHCP allocation status recheck, connectivity test, latency test, packet loss rate test, or DNS resolution test. This yields the verification result for each candidate fault cause. Then, based on the degree of matching between the candidate fault cause and the fault symptom event sequence, the degree of matching between the suspected fault location corresponding to the candidate fault cause and the actual affected fault entity node, the degree of support of the active verification results for the candidate fault cause, and the degree of matching between the candidate fault cause and the user's fault report text, the confidence level of each candidate fault cause is calculated.

[0182] The diagnostic output module is used to determine the root cause of the target fault based on the confidence level of each candidate fault cause and output the fault diagnosis results of the FTTR optical gateway.

[0183] Specifically, the diagnostic output module sorts candidate fault causes from highest to lowest confidence level. When the candidate fault cause with the highest confidence level meets the target fault root cause determination criteria, it is identified as the target fault root cause. When there is strong competition among multiple candidate fault causes, the module reviews the results based on the sorting of symptom matching parameters, topology matching parameters, verification support parameters, and fault reporting matching parameters. Based on the review results, the target fault root cause is determined, or a manual review result is output. Further, after determining the target fault root cause, the diagnostic output module identifies the affected optical gateways, fault locations, terminals, and services based on the suspected fault location corresponding to the target fault root cause and the FTTR fault association diagram, and generates corresponding handling plans according to the fault handling rules.

[0184] Furthermore, the intelligent reasoning module includes a retrieval enhancement unit and a large model reasoning unit.

[0185] The retrieval enhancement unit is used to acquire the FTTR fault knowledge base, retrieve matching fault knowledge fragments based on abnormal features in the fault symptom event sequence, extract the topological association context of abnormal nodes by combining the FTTR fault association graph, and generate retrieval enhancement diagnostic context.

[0186] Specifically, the retrieval enhancement unit generates retrieval information for the current fault based on the abnormal objects and types in the fault symptom event sequence, as well as the fault phenomena and affected services in the user's fault report text. This retrieval information is then matched with pre-stored fault types, fault objects, abnormal indicators, fault phenomena, and handling rules in the FTTR fault knowledge base to obtain fault knowledge fragments related to the current fault. Simultaneously, based on the corresponding nodes of the abnormal objects in the FTTR fault association graph, the retrieval enhancement unit extracts upstream and downstream fault entity nodes along the influence direction of the connecting edges to form a topological association context. Finally, the fault symptom event sequence, fault knowledge fragments, and topological association context are combined into a retrieval enhancement diagnostic context.

[0187] The large model inference unit is used to input the retrieved enhanced diagnostic context into the large model and output a set of candidate fault causes, as well as supporting evidence, conflicting evidence, diagnostic inference chain and recommended verification actions for each candidate fault cause.

[0188] Specifically, the large model inference unit inputs the retrieved enhanced diagnostic context into the large model. The large model then determines the chronological relationship between different anomalies based on their occurrence time, whether the anomalies are located on the same impact path based on the anomaly object and the FTTR fault correlation graph, determines the possible fault cause type corresponding to the anomaly phenomenon based on fault knowledge fragments, and determines whether the candidate fault causes can explain the actual impact range based on the affected objects, thereby outputting a set of candidate fault causes. For each candidate fault cause, the large model inference unit also outputs the corresponding fault cause type, suspected fault location, supporting evidence, conflicting evidence, impact range, diagnostic inference chain, and recommended verification actions.

[0189] Furthermore, the confidence assessment module includes an active verification unit and a confidence calculation unit.

[0190] The active verification unit is used to match the corresponding verification items according to the fault type of each candidate fault cause, perform active verification, and output the verification result of each candidate fault cause.

[0191] Specifically, the active verification unit determines the verification items based on the fault cause type of the candidate fault. When the candidate fault cause is an optical link anomaly, it performs received optical power retesting, PON registration status rechecking, and optical link alarm rechecking. When the candidate fault cause is a master-slave optical gateway connection anomaly, it performs slave optical gateway online status query, master-slave optical gateway connection status query, and indoor fiber optic link status query. When the candidate fault cause is a wireless access anomaly, it performs wireless signal strength rechecking, channel utilization detection, and wireless interference strength detection. When the candidate fault cause is a gateway system anomaly, it performs CPU utilization rechecking, memory utilization rechecking, and DHCP allocation status rechecking. When the candidate fault cause is a service experience anomaly, it performs connectivity testing, latency testing, packet loss rate testing, and DNS resolution testing. The active verification unit summarizes the execution results of the active verification into a verification result, which includes verification supported items, verification unsupported items, and verification anomaly objects.

[0192] The confidence calculation unit is used to calculate the symptom matching parameters, topology matching parameters, verification support parameters, and fault reporting matching parameters of the candidate fault causes, and generate the confidence score of each candidate fault cause based on the four types of parameters.

[0193] Specifically, the confidence calculation unit calculates symptom matching parameters based on the degree of matching between candidate fault causes and abnormal events in the fault symptom event sequence; it calculates topology matching parameters based on the degree of matching between the suspected fault location corresponding to the candidate fault cause and the actual affected fault entity node in the FTTR fault association diagram; it calculates verification support parameters based on the degree of support of the active verification results for the candidate fault cause; it calculates fault reporting matching parameters based on the degree of matching between the candidate fault cause and the fault location, fault phenomenon, and affected services in the user fault reporting text; and finally, it calculates the confidence of the candidate fault cause based on the symptom matching parameters, topology matching parameters, verification support parameters, and fault reporting matching parameters.

[0194] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. A fault diagnosis method for FTTR optical gateways based on large model inference, characterized in that, include: Obtain FTTR topology information, optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text from the FTTR optical gateway; FTTR topology association structure is constructed based on FTTR topology information, and the node status of each faulty entity node is determined based on optical link information, optical gateway operation information, wireless access information and service experience information, and an FTTR fault association diagram is generated. Based on optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text, a fault symptom event sequence is generated; Based on the fault symptom event sequence and FTTR fault association graph, a retrieval-enhanced diagnostic context for FTTR optical gateway fault diagnosis is constructed and input into a large model to generate a set of candidate fault causes, as well as a diagnostic reasoning chain and recommended verification actions corresponding to each candidate fault cause. Active verification is performed based on the recommended verification action corresponding to each candidate fault cause, and the verification result corresponding to each candidate fault cause is obtained. Calculate the confidence level of each candidate fault cause based on the verification results, fault symptom event sequence, diagnostic inference chain, user fault report text, and FTTR fault association diagram. The root cause of the target fault is determined based on the confidence level of each candidate fault cause, and the fault diagnosis results of the FTTR optical gateway are output.

2. The FTTR optical gateway fault diagnosis method based on large model inference according to claim 1, characterized in that, The process of constructing an FTTR topology association structure based on FTTR topology information, and determining the node status of each faulty entity node based on optical link information, optical gateway operation information, wireless access information, and service experience information, to generate an FTTR fault association diagram, specifically includes: Based on the FTTR topology information, the master optical gateway, slave optical gateway, indoor fiber optic link, wireless access unit and terminal are extracted as faulty entity nodes and connection edges are established between the faulty entity nodes. Determine the node status of each faulty entity node. The node status includes online status, abnormal performance status, and service impact status. The node status of the main optical gateway, slave optical gateway, and indoor fiber optic link also includes alarm status. Determine the influence direction of each connection edge, whereby the influence direction is used to represent the influence relationship between the upstream faulty entity node and the downstream faulty entity node or terminal; Generate an FTTR fault association graph based on the faulty entity node, connecting edge, node status, and influence direction.

3. The FTTR optical gateway fault diagnosis method based on large model inference according to claim 1, characterized in that, The step of generating a fault symptom event sequence based on the optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text specifically includes: Time alignment and anomaly detection are performed on optical link information, optical gateway operation information, wireless access information, and service experience information; Optical link anomalies, gateway operation anomalies, wireless access anomalies, and service experience anomalies occurring within the same time window are respectively converted into fault symptom events. Each fault symptom event includes the event occurrence time, the abnormal object, the anomaly type, the anomaly index value, the anomaly duration, and the affected object. Perform semantic parsing on user fault reports to extract fault location, fault symptoms, affected services, and fault time; Map the fault location to the optical gateway, wireless access unit or terminal node in the FTTR fault association diagram, map the affected service to the terminal node carrying the service or as the service impact attribute of the corresponding terminal node, and generate fault symptom events obtained by parsing the user's fault report text. The fault symptom events are sorted according to their occurrence time to obtain a fault symptom event sequence.

4. The FTTR optical gateway fault diagnosis method based on large model inference according to claim 1, characterized in that, The process involves constructing a retrieval-enhanced diagnostic context for FTTR optical gateway fault diagnosis based on the fault symptom event sequence and the FTTR fault association graph. This context is then input into a large model to generate a set of candidate fault causes, as well as a diagnostic inference chain and recommended verification actions corresponding to each candidate fault cause. Specifically, this includes: The FTTR fault knowledge base is obtained. Based on the abnormal objects, abnormal types, fault phenomena and affected services in the fault symptom event sequence, fault knowledge fragments are retrieved from the FTTR fault knowledge base. The FTTR fault knowledge base includes optical link anomaly knowledge, master-slave optical gateway connection anomaly knowledge, wireless coverage anomaly knowledge, gateway system anomaly knowledge, service connectivity anomaly knowledge and fault handling rules. Based on the FTTR fault association graph, extract the upstream fault entity nodes, downstream fault entity nodes and affected terminals related to the abnormal object to generate a topology association context. The fault symptom event sequence, fault knowledge fragments, and topological association context are combined into a retrieval-enhanced diagnostic context and input into a large model to generate a set of candidate fault causes. Each candidate fault cause includes fault cause type, suspected fault location, supporting evidence, conflicting evidence, scope of impact, and recommended verification action. Based on the supporting evidence, conflicting evidence, and connection relationships in the FTTR fault association graph corresponding to each candidate fault cause, a corresponding diagnostic reasoning chain is generated.

5. The FTTR optical gateway fault diagnosis method based on large model inference according to claim 1, characterized in that, The step of performing active verification based on the recommended verification action corresponding to each candidate fault cause to obtain the verification result corresponding to each candidate fault cause specifically includes: When the candidate fault cause is an optical link abnormality, perform received optical power retest, PON registration status recheck and optical link alarm recheck. When the candidate fault cause is an abnormal connection between the master and slave optical gateways, execute the online status query of the slave optical gateway, the connection status query of the master and slave optical gateways, and the status query of the indoor fiber optic link. When the candidate fault cause is a wireless access anomaly, perform wireless signal strength review, channel utilization detection, and wireless interference strength detection. When the candidate fault cause is a gateway system abnormality, perform CPU utilization review, memory utilization review, and DHCP allocation status review. When the candidate fault cause is an abnormal business experience, perform connectivity tests, latency tests, packet loss rate tests, and DNS resolution tests. Based on the results of the active verification, the verification result corresponding to each candidate fault cause is obtained.

6. The FTTR optical gateway fault diagnosis method based on large model inference according to claim 1, characterized in that, The step of calculating the confidence level of each candidate fault cause based on the verification results, fault symptom event sequence, diagnostic inference chain, user fault report text, and FTTR fault correlation graph corresponding to each candidate fault cause specifically includes: Calculate the degree of matching between candidate fault causes and abnormal events in the fault symptom event sequence, and calculate symptom matching parameters based on the degree of matching between candidate fault causes and abnormal events in the fault symptom event sequence; Calculate the degree of matching between the suspected fault location corresponding to the candidate fault cause and the affected fault entity node in the FTTR fault association diagram. Based on the degree of matching between the suspected fault location corresponding to the candidate fault cause and the affected fault entity node in the FTTR fault association diagram, calculate the topology matching parameters. Calculate the degree of support of the active verification results for the candidate fault causes, and calculate the verification support parameters based on the degree of support of the active verification results for the candidate fault causes; Calculate the degree of matching between candidate fault causes and fault location, fault phenomenon and affected services in user fault report text; and calculate fault reporting matching parameters based on the degree of matching between candidate fault causes and fault location, fault phenomenon and affected services in user fault report text. Calculate the confidence level of candidate fault causes based on symptom matching parameters, topology matching parameters, verification support parameters, and fault reporting matching parameters.

7. The FTTR optical gateway fault diagnosis method based on large model inference according to claim 1, characterized in that, The process of determining the target fault root cause based on the confidence level of each candidate fault cause and outputting the FTTR optical gateway fault diagnosis result specifically includes: The candidate fault causes are sorted from high to low confidence level to obtain the root cause ranking results. When the confidence level of the candidate fault cause with the highest confidence level is greater than the sum of the confidence levels of all other candidate fault causes, the candidate fault cause with the highest confidence level is determined as the target fault root cause. When the confidence of the candidate fault cause with the highest confidence is less than or equal to the sum of the confidence of all other candidate fault causes, all candidate fault causes are independently sorted according to the symptom matching parameter, topology matching parameter, verification support parameter, and fault reporting matching parameter, respectively. Determine whether the order of the four parameters of the candidate fault cause with the highest confidence is the first among the candidate fault causes. If all of them are first, then the candidate fault cause with the highest confidence is determined as the target fault root cause. If not all of them are first, then output the diagnosis result to be manually reviewed and send the fault root cause ranking result, diagnosis inference chain and verification result to the operation and maintenance end. Once the root cause of the target fault is determined, the affected optical gateways, locations, terminals, and services are identified based on the suspected fault location corresponding to the root cause of the target fault and the FTTR fault correlation diagram. Based on the root cause of the target fault and the fault handling rules, a handling plan is generated. The handling plan includes remotely restarting the optical gateway, restoring the gateway configuration, adjusting the wireless channel, optimizing the wireless transmission parameters, reallocating terminal access, retesting the optical link, prompting the user to check the indoor fiber optic connection, and generating on-site dispatch suggestions.

8. A fault diagnosis system for FTTR optical gateways based on large model inference, used to implement the fault diagnosis method for FTTR optical gateways based on large model inference as described in any one of claims 1-7, characterized in that, include: The data acquisition module is used to acquire FTTR topology information, optical link information, optical gateway operation information, wireless access information, service experience information, and user fault report text of the FTTR optical gateway; The fault scenario modeling module is used to construct the FTTR topology association structure based on FTTR topology information, determine the node status of each fault entity node based on optical link information, optical gateway operation information, wireless access information and service experience information, generate the FTTR fault association diagram, and generate the fault symptom event sequence based on optical link information, optical gateway operation information, wireless access information, service experience information and user fault report text. The intelligent reasoning module is used to construct a retrieval-enhanced diagnostic context based on the fault symptom event sequence and FTTR fault association graph, and input it into the large model to generate a set of candidate fault causes, as well as the diagnostic reasoning chain and recommended verification actions corresponding to each candidate fault cause; The confidence assessment module is used to perform active verification based on the recommended verification action corresponding to each candidate fault cause to obtain the verification result, and to calculate the confidence of each candidate fault cause by combining the diagnostic inference chain, fault symptom event sequence, user fault report text and FTTR fault association graph. The diagnostic output module is used to determine the root cause of the target fault based on the confidence level of each candidate fault cause and output the fault diagnosis results of the FTTR optical gateway.

9. The FTTR optical gateway fault diagnosis system based on large model inference according to claim 8, characterized in that, The intelligent reasoning module includes: The retrieval enhancement unit is used to obtain the FTTR fault knowledge base, retrieve matching fault knowledge fragments based on abnormal features in the fault symptom event sequence, extract the topological association context of abnormal nodes by combining the FTTR fault association graph, and generate retrieval enhancement diagnostic context. The large model inference unit is used to input the retrieved enhanced diagnostic context into the large model and output a set of candidate fault causes, as well as supporting evidence, conflicting evidence, diagnostic inference chain and recommended verification actions for each candidate fault cause.

10. The FTTR optical gateway fault diagnosis system based on large model inference according to claim 8, characterized in that, The confidence assessment module includes: The active verification unit is used to match the corresponding verification items according to the fault type of each candidate fault cause, perform active verification, and output the verification result of each candidate fault cause. The confidence calculation unit is used to calculate the symptom matching parameters, topology matching parameters, verification support parameters, and fault reporting matching parameters of the candidate fault causes, and generate the confidence score of each candidate fault cause based on the four types of parameters.

Images