A communication network exception handling method, apparatus and device

Abstract

The application discloses a communication network exception handling method, device and equipment, and relates to the technical field of intelligent communication network operation and maintenance. The method comprises the following steps: converting heterogeneous exception information into an exception request with a unified structure through normalization processing; performing object positioning under the constraint of a body composed of a resource body, an operation and maintenance body and an organization body; generating a complete positioning result containing resources, operation and maintenance, organizations and relationship paths; and constructing a judgment context bearing object semantics, index semantics, relationship semantics and constraint conditions based on the exception request and the positioning result, so that the judgment of a handling rule is established on the basis of unified and interpretable input, and finally an exception handling result is output.

Description

Technical Field

[0001] This application relates to the field of intelligent operation and maintenance technology for communication networks, and more specifically, to a method, apparatus, and device for handling communication network anomalies. Background Technology

[0002] As communication networks continue to expand, their architectures exhibit characteristics such as a wide variety of devices, large hierarchical spans, complex topological relationships, and dense service loads. During network operation, a massive amount of abnormal information is continuously generated, including alarms, exceeding performance limits, and link disturbances. In actual operation and maintenance, anomaly handling typically focuses on information such as performance limit violations, alarm events, status changes, or findings during inspections. However, this anomaly information often only reflects local observations and is difficult to directly indicate the corresponding real network objects, the scope of impact, and the handling methods.

[0003] Current communication network anomaly handling technologies generally suffer from the following problems: inconsistent expression and format of anomaly information, making it difficult to effectively correlate data from different sources; inaccurate identification of network objects involved in the anomaly, leading to location errors; risk assessment based on relatively singular factors, failing to comprehensively reflect the actual impact of the anomaly; lack of flexibility and adaptability in the rule matching process, easily resulting in missed or false positives; and limited automation, requiring manual intervention in many stages. These problems make it difficult to accurately locate network anomalies, failing to fully meet the intelligent operation and maintenance needs of large-scale, complex communication networks. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, and device for handling communication network anomalies, in order to solve the problem that existing technologies make it difficult to accurately locate network anomalies and cannot fully meet the intelligent operation and maintenance needs of large-scale and complex communication networks.

[0005] To achieve the above objectives, the first aspect of this application proposes a method for handling communication network anomalies, comprising: Obtain abnormal information from the communication network; Using normalization processing, the abnormal information is converted into a corresponding abnormal request structure, which includes an abnormal type, a set of candidate object identifiers, an indicator type, an abnormal value, a time window, a set of condition items, and a source system identifier. Under ontology constraints, ontology-driven object localization is performed on the abnormal request structure based on the semantic model, generating abnormal object localization results. The semantic model includes resource ontology, operation and maintenance ontology, and organization ontology. The abnormal object localization results include a set of resource objects, a set of operation and maintenance objects, a set of organization objects, and a set of object relationship paths. The ontology constraints include object type constraints, indicator applicable object constraints, object relationship path constraints, action applicable condition constraints, and rule applicable scope constraints. Based on the abnormal request structure and the abnormal object location result, a decision context is generated using the ontology constraint. The decision context is used to carry the object semantics, indicator semantics, relational semantics and constraint conditions required for rule determination. Based on the judgment context, the handling rules are executed to determine the exception handling result.

[0006] Secondly, a communication network anomaly handling device is proposed, comprising: The acquisition module is used to acquire abnormal information from the communication network. The processing module is used to convert the abnormal information into a corresponding abnormal request structure using normalization processing. The abnormal request structure includes an abnormal type, a set of candidate object identifiers, an indicator type, an abnormal value, a time window, a set of condition items, and a source system identifier. The localization module is used to perform ontology-driven object localization on the abnormal request structure based on the semantic model under ontology constraints, and generate abnormal object localization results. The semantic model includes resource ontology, operation and maintenance ontology, and organization ontology. The abnormal object localization results include a set of resource objects, a set of operation and maintenance objects, a set of organization objects, and a set of object relationship paths. The ontology constraints include object type constraints, indicator applicable object constraints, object relationship path constraints, action applicable condition constraints, and rule applicable scope constraints. The generation module is used to generate a decision context based on the abnormal request structure and the abnormal object location result, using the ontology constraints. The decision context is used to carry the object semantics, indicator semantics, relational semantics and constraint conditions required for rule determination. The judgment module is used to perform judgment based on the judgment context and obtain the exception handling result.

[0007] Thirdly, an electronic device is proposed, comprising: At least one processor; and The memory is communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0008] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements any of the methods in the embodiments of this disclosure.

[0009] Fifthly, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of the present disclosure.

[0010] The technical solutions provided by the embodiments of this application may include the following beneficial effects: In this application, heterogeneous anomaly information is converted into anomaly requests with a unified structure through normalization processing. Object localization is performed under the constraints of an ontology jointly constituted by resource ontology, operation and maintenance ontology, and organization ontology, generating a complete localization result containing resources, operation and maintenance, organization, and relationship paths. Based on the anomaly requests and localization results, a judgment context carrying object semantics, indicator semantics, relationship semantics, and constraint conditions is constructed, so that the judgment of handling rules is based on unified and interpretable input, and the anomaly handling result is finally output. This significantly improves the accuracy and completeness of anomaly object localization, ensures the uniformity and consistency of rule judgment, enhances the interpretability and traceability of handling results, and realizes the fully automated processing from anomaly information acquisition to handling result output, effectively adapting to the intelligent operation and maintenance needs of large-scale complex communication networks. Attached Figure Description

[0011] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings: Figure 1 A flowchart illustrating a communication network anomaly handling method provided in this application; Figure 2 A schematic diagram illustrating an application scenario provided for this application; Figure 3 A schematic diagram illustrating another application scenario provided in this application; Figure 4 A schematic diagram illustrating yet another application scenario provided in this application; Figure 5 This application provides a schematic diagram of the structure of a communication network anomaly handling device; Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] In this application, the terms "upper," "lower," "left," "right," "front," "rear," "top," "bottom," "inner," "outer," "middle," "vertical," "horizontal," "lateral," and "longitudinal" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are primarily for the purpose of better describing this application and its embodiments, and are not intended to limit the indicated device, element, or component to having a specific orientation, or to be constructed and operated in a specific orientation.

[0015] Furthermore, in addition to indicating location or positional relationship, some of the aforementioned terms may also have other meanings. For example, the term "above" may also be used in some cases to indicate a certain dependency or connection relationship. Those skilled in the art can understand the specific meaning of these terms in this application based on the specific circumstances.

[0016] Furthermore, the terms "installation," "setup," "equipped with," "connection," "linked," and "socketing" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral structure; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, or an internal connection between two devices, components, or parts. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0017] Currently, existing technologies related to handling communication network anomalies mainly include the following categories: The first category is anomaly detection schemes based on thresholds or alarms. These schemes take exceeding metric limits, state changes, or alarm triggers as input, and identify anomalies through threshold comparisons, conditional triggers, or simple logical judgments. While these schemes primarily address the question of "is it abnormal?", they struggle to determine the specific network object corresponding to the anomaly and provide the necessary contextual information for anomaly handling.

[0018] The second category is judgment schemes based on rule bases or alarm correlations. These schemes comprehensively judge multiple inputs through rule expressions, expert rules, or alarm correlation relationships. While these schemes can handle a certain degree of complex conditions, the rule inputs are usually still discrete indicators, discrete alarms, or discrete events, lacking a unified object semantic foundation, resulting in unstable rule applicability boundaries.

[0019] The third category comprises auxiliary analysis solutions based on knowledge graphs, ontology, or semantic models. These solutions enhance the system's ability to express network structures and object relationships by establishing semantic models of resource objects, operational objects, and relationships. While these solutions improve object relationship representation and auxiliary analysis capabilities, they are primarily used for retrieval, display, or diagnostic assistance, and have not yet formed an integrated processing flow from abnormal input to handling and judgment.

[0020] The aforementioned existing technologies have the following shortcomings in practical applications: (1) There is a lack of stable mapping between abnormal inputs and real network objects. Abnormal information often only corresponds to local observation results and is difficult to map stably to real network objects such as computer rooms, equipment, boards, ports, and links.

[0021] (2) There is a lack of a unified relationship foundation among resource objects, operation and maintenance objects and organizational objects. The above-mentioned objects are usually maintained independently in different systems. When handling anomalies, it is often necessary to manually piece together object relationships between multiple systems, making it difficult to automatically form a consistent object chain and responsibility chain.

[0022] (3) The rule determination lacks unified semantic constraints. The rule input is usually discrete indicators, discrete alarms or discrete events. The applicable objects, applicable indicators and applicable relationship paths of the rules lack unified expression, resulting in poor consistency of rule determination.

[0023] (4) The scope of application and judgment criteria of the rules are not stable enough. Existing rule judgment schemes often directly perform matching on the entire rule set or a large-scale rule set, which is prone to problems such as unclear scope of application, rule conflicts, missed judgments or misjudgments. The same anomaly may result in inconsistent handling judgments in different systems, different work groups or different scenarios.

[0024] (5) The handling results lack clear judgment criteria. The anomaly judgment results output by the existing schemes usually lack object basis, rule basis, and relationship basis, making it difficult to clearly answer which object the result is for, which relationship path it is based on, and which set of rules it is based on, resulting in insufficient interpretability, verifiability, and traceability of the results.

[0025] Figure 1 This application provides a flowchart illustrating a method for handling communication network anomalies. The method may include: S110. Obtain abnormal information from the communication network.

[0026] In this embodiment, abnormal information refers to data observation results generated during the operation of the communication network that may indicate abnormalities in the status of network devices or links. Abnormal information can originate from performance monitoring systems, alarm systems, status monitoring systems, inspection systems, or work order systems, etc. Abnormal information may include: performance indicator limit exceeding information, such as port received optical power below a threshold, device CPU utilization exceeding a set threshold, and increased link bit error rate; alarm event information, such as device disconnection alarms, port LOS (loss of signal) alarms, and link intermittent disconnection alarms; status change information, such as device master / slave switching, card insertion / removal, and port up / down status changes; inspection discovery information, abnormal records discovered through manual or automated inspections, such as excessive fiber attenuation and abnormal device temperature; and existing associated work orders or task information, including work order records related to historical abnormalities or incomplete maintenance tasks.

[0027] S120. Using normalization processing, the abnormal information is converted into a corresponding abnormal request structure, wherein the abnormal request structure includes an abnormal type, a set of candidate object identifiers, an indicator type, an abnormal value, a time window, a set of condition items, and a source system identifier.

[0028] In this embodiment, normalization processing is used to uniformly parse, map, and organize the original abnormal information with different formats and field specifications, eliminate redundant and invalid fields, and unify the original abnormal data from multiple sources into a fixed-format abnormal request structure, thereby eliminating the data format differences between different network management and monitoring systems.

[0029] Specifically, normalization includes at least the following operations: (1) Object identifier normalization Based on the unified resource coding, pre-configured object alias mapping table, and object naming resolution rules in the resource system, device abbreviations, port abbreviations, and names with hierarchical semantics (such as "1 frame 1 slot 5 ports" or "PON1 / 1 / 5") appearing in the original anomaly information are converted into standardized resource object identifiers. When the original anomaly information only contains alarm mounted objects or task mounted objects, the standard object identifier is obtained by reverse lookup through the mounting relationship. In practice, if multiple possible object identifiers still exist after the above processing, all of them are retained as a set of candidate object identifiers for further filtering in subsequent object location steps.

[0030] (2) Normalization of indicator expression Based on the indicator dictionary, monitoring item mapping rules, and indicator alias mapping rules, different indicator expressions in the original anomaly information are converted into a unified standard indicator type. For alarm information, it is mapped to the corresponding alarm type based on the alarm code or alarm name, and further associated with the corresponding indicator type when necessary.

[0031] (3) Time information normalization The sampling time, alarm occurrence time, duration, and continuous monitoring window information in the original anomaly information are converted into a unified time window structure. The time window structure includes at least a start time, end time, duration, number of windows, and window type. A single-point anomaly corresponds to a single-point window, and anomalies spanning N consecutive monitoring cycles correspond to a continuous monitoring window, with the corresponding number of windows recorded.

[0032] (4) Normalization of conditional information The conditional descriptions carried in the original anomaly information (such as "continuous exceedance of limits", "instantaneous fluctuation", "recovery", "linked alarm", "accompanying error code", "existing associated work order", etc.) are converted into a set of condition items. The condition items can be extracted or determined from monitoring data, alarm records, and work order system records.

[0033] (5) Merging of multiple anomalies When the same anomaly originates from different sources such as the monitoring system and the alarm system, it is merged based on the consistency of the candidate object identifiers and the overlap of the time windows. If the candidate object identifiers corresponding to two original anomaly information are the same or have an inclusion relationship, and their time windows overlap, they are merged into the same anomaly event, and the indicator type and indicator value obtained from the monitoring side and the condition items obtained from the alarm side are written into the same anomaly request structure.

[0034] After normalization, a unified exception request structure is generated. This structure can include exception type, object candidate identifier set, indicator type, exception value, time window, condition item set, and source system identifier. Specifically, the exception type indicates whether the current exception is a performance indicator exception, alarm exception, status exception, or task exception; the object candidate identifier set records one or more resource objects that may be associated with the current exception; the indicator type records the standard indicator category involved in the current exception; the exception value retains quantitative information such as the original observed indicator limit exceeding value or alarm level; the time window records the unified time range and window characteristics corresponding to the current exception; the condition item set records additional conditions such as persistence, linkage, and recoverability; and the source system identifier records the source of the current exception.

[0035] For example, upon receiving two raw inputs: the monitoring system inputs "The received optical power of port PON1 / 1 / 5 has been below -27dBm for three consecutive monitoring cycles," and the alarm system inputs "A LOS alarm has occurred at port 1, slot 1, port 5." After normalization, an anomaly request structure is generated: the anomaly type is performance indicator anomaly; the object candidate identifier set contains a unified port object identifier; the indicator type is optical power; the anomaly value is below the threshold and LOS alarm; the time window is three consecutive monitoring cycles; the condition item set includes continuous over-limit and linked alarms; and the source system identifiers are the monitoring system and the alarm system.

[0036] S130. Under ontology constraints, perform ontology-driven object localization on the abnormal request structure based on the semantic model to generate abnormal object localization results. The semantic model includes resource ontology, operation and maintenance ontology, and organization ontology. The abnormal object localization results include a set of resource objects, a set of operation and maintenance objects, a set of organization objects, and a set of object relationship paths. The ontology constraints include object type constraints, indicator applicable object constraints, object relationship path constraints, action applicable condition constraints, and rule applicable scope constraints.

[0037] In this embodiment, the semantic model may include a resource ontology, an operation and maintenance ontology, an organization ontology, etc., wherein the resource ontology is used to describe various resource objects in the communication network and their hierarchical and connection relationships. Objects in the resource ontology may include data centers, equipment, boards, ports, links, and circuits, etc.; relationships in the resource ontology may include the attribution relationship between data centers and equipment, the installation relationship between equipment and boards, the carrying relationship between boards and ports, the connection relationship between ports and links, and the carrying relationship between links and circuits, etc. The resource ontology is used to support resource object location and object relationship path completion.

[0038] The operations and maintenance (O&M) ontology describes the O&M objects and their relationships involved in the communication network O&M process. Objects in the O&M ontology can include alarms, faults, work orders, tasks, inspection records, and maintenance actions; relationships can include the relationships between resource objects and alarm objects, alarm objects and fault objects, fault objects and work order objects, work order objects and task objects, and task objects and maintenance actions. The O&M ontology supports the location of O&M objects.

[0039] An organizational ontology describes the organizational objects and their responsibilities involved in the maintenance of communication networks. Objects in an organizational ontology can include geographical units, professional units, maintenance units, responsible work teams, positions, and responsible individuals. Relationships within the organizational ontology can include management relationships between geographical units and professional units, affiliation relationships between professional units and maintenance units, organizational relationships between maintenance units and responsible work teams, responsibility relationships between responsible work teams and positions, and responsibility relationships between positions and responsible individuals. The organizational ontology supports the location of organizational objects.

[0040] Ontology constraints provide a unified constraint basis for locating abnormal objects and subsequent rule determination. These constraints can include object type constraints, indicator applicability object constraints, object relationship path constraints, action applicability condition constraints, and rule applicability scope constraints. Specifically, object type constraints limit the range of object levels that a certain type of abnormal input can map to; for example, some abnormalities are only allowed to fall on port objects or link objects, while others are only allowed to fall on device objects or data center objects. Indicator applicability object constraints limit which type of object a certain indicator preferentially applies to; for example, optical power indicators preferentially apply to port objects or link objects, not data center objects. Object relationship path constraints limit the range of object relationship paths completed upstream or downstream from the current target object; for example, from a port object, board objects, device objects, data center objects, and link objects can be completed, but cannot be arbitrarily expanded outside the predefined relationship path. Action applicability condition constraints limit the conditions under which a certain type of action is allowed to output; for example, dispatch suggestions or escalation handling suggestions are only allowed to be output when continuous limit violations, linked alarms, or high-risk conditions are met. Rule scope constraints are used to limit which object types, indicator types, relationship paths, time windows, and conditional expressions a certain type of rule applies to.

[0041] The localization process uses the set of candidate object identifiers within the abnormal request structure as the retrieval entry point. Candidate resources are matched within the resource ontology. Then, relying on the relationships between ontologities, the system retrieves related alarms and work order information from the operations and maintenance ontology, and matches the corresponding responsible operations and maintenance entity within the linked organizational ontology. Simultaneously, the system parses the topological links between objects in the resource ontology's topology data to obtain the associated paths between objects, ultimately yielding the abnormal object localization result. The abnormal object localization result can include a set of resource objects, a set of operations and maintenance objects, a set of organizational objects, and a set of object relationship paths. The resource object set represents the actual network objects involved in the abnormality (such as data centers, equipment, boards, ports, links, circuits, etc.); the operations and maintenance object set represents the alarms, faults, work orders, or task objects involved in the abnormality; the organizational object set represents the responsible organizational unit corresponding to the abnormality (such as maintenance unit, responsible team, position, responsible person, etc.); and the object relationship path set represents the relationship chains between the above objects.

[0042] S140. Based on the abnormal request structure and the abnormal object location result, a decision context is generated using the ontology constraint, wherein the decision context is used to carry the object semantics, indicator semantics, relational semantics and constraint conditions required for rule determination.

[0043] In this embodiment, a structured decision context is generated by combining a standardized exception request structure with the results of locating exception objects across all dimensions, and integrating, calculating, and encapsulating various preset ontology constraints. The decision context can carry four core semantic information categories: first, object semantics, including the type and attribute information of valid resource objects, operation and maintenance objects, and organizational objects after ontology constraint matching; second, indicator semantics, including the indicator type, exception value, limit-crossing characteristics, and monitoring time window information corresponding to the exception; third, relational semantics, including complete object relationship path information such as topological hierarchy, mounting associations, and business associations between related objects; and fourth, constraint conditions, including standardized constraint expressions, rule application scope, and action constraint conditions compiled based on the original exception conditions.

[0044] S150. Based on the judgment context, the handling rules are executed to determine the exception handling result.

[0045] In this embodiment, relying on the generated structured judgment context, a preset set of network anomaly handling rules is invoked to conduct comprehensive and refined rule matching and anomaly analysis. Combining the object semantics, indicator semantics, relational semantics, constraints, and calculated risk levels carried by the judgment context, the selection and implementation of suitable rules are completed, ultimately outputting anomaly handling results adapted to the current anomaly scenario. Anomaly handling results may include observation, review, dispatch suggestions, and escalation handling suggestions.

[0046] Specifically, the criteria for determining the outcome of anomaly handling are as follows: Observation: If the anomaly is only manifested as a short-term fluctuation (e.g., only one monitoring window is abnormal), does not meet the condition of persistence, and there are no linked alarms or other high-risk additional conditions, no manual intervention is required; monitoring can continue.

[0047] Verification: If the anomaly meets the conditions for continuous exceeding of limits (e.g., ≥3 consecutive monitoring windows), but is not accompanied by a triggering alarm, and the risk level does not reach high risk, it is recommended that operations and maintenance personnel manually verify the anomaly to confirm whether there are any potential risks.

[0048] Work order recommendation: If the anomaly meets the conditions for continuous exceeding of limits and there are linked alarms or a clear impact path, it is recommended to generate a work order and assign it to the responsible team for handling.

[0049] Upgrade Recommendation: If the anomaly meets the conditions for continuous exceeding limits, triggers related alarms, and reaches a high-risk level (e.g., involving critical links or main business paths), it is recommended to upgrade the handling immediately, which may involve higher-level operational intervention or emergency cutover.

[0050] According to the embodiments of this application, heterogeneous anomaly information is converted into anomaly requests with a unified structure through normalization processing. Object localization is performed under the constraints of the resource ontology, operation and maintenance ontology, and organization ontology, generating a complete localization result containing resources, operation and maintenance, organization, and relationship paths. Based on the anomaly request and localization result, a judgment context carrying object semantics, indicator semantics, relationship semantics, and constraint conditions is constructed, so that the judgment of the handling rules is based on a unified and interpretable input, and finally the anomaly handling result is output. This significantly improves the accuracy and completeness of anomaly object localization, ensures the uniformity and consistency of rule judgment, enhances the interpretability and traceability of the handling result, and realizes the fully automated processing from anomaly information acquisition to handling result output, effectively adapting to the intelligent operation and maintenance needs of large-scale complex communication networks.

[0051] In practice, along with the anomaly handling results, the corresponding judgment criteria are also output so that operations and maintenance personnel can understand the reasoning and conduct review or traceability. Judgment criteria may include: the anomaly object location result (such as the set of objects involved and their relationship paths); the hit rules (such as rule identifiers and rule content); the ontology constraints used; the current risk level; the applicable time window; and the object relationship path criteria.

[0052] By establishing the handling rules under a unified judgment context constraint, similar anomalies can form consistent handling judgments based on unified object semantics, unified rule semantics, and unified action boundaries. At the same time, the output handling results have clear interpretability and traceability.

[0053] In one implementation, the ontology-driven object localization of the abnormal request structure, based on a semantic model and under ontology constraints, to generate an abnormal object localization result, may include: Based on the abnormal request structure, the target resource object is retrieved in the resource ontology, and the upstream and downstream resource objects associated with the target resource object are completed according to the object relationship path constraints. Using object relationships, the target operation and maintenance object corresponding to the target resource object is retrieved in the operation and maintenance ontology. The object relationship is pre-established between resource objects, operation and maintenance objects, and organization objects. The operation and maintenance objects include alarm objects, fault objects, work order objects, and task objects. Based on the target resource object and the target operation and maintenance object, the target organization object is retrieved in the organization ontology using the object relationship. The organization object includes maintenance unit, responsible team, position and responsible person. Based on the target resource object, the target operation and maintenance object, and the target organization object, generate the abnormal object location result.

[0054] In this embodiment, resource objects can refer to various physical and logical network resources in a communication network, including network entities such as computer rooms, equipment, boards, ports, transmission links, and topology nodes. Maintenance objects can refer to event-type and task-type objects related to the operation and maintenance of network resources, specifically including alarm objects generated by device ports, recorded fault objects, dispatched work order objects, and maintenance task objects to be executed. Organizational objects can refer to the organizations and personnel responsible for network maintenance, covering maintenance units under maintenance jurisdiction, specialized responsibility teams, maintenance positions, and specific maintenance personnel.

[0055] Based on configuration, mounting, and flow relationships, object relationships are established between resource objects, operation and maintenance objects, and organizational objects. These relationships can be pre-built offline and persistently stored. During a single exception handling process, the pre-built object relationships are directly read, eliminating the need for real-time creation. Configuration relationships represent the static attribution configurations between resources and operation and maintenance / organizational entities; mounting relationships represent the binding relationships between alarms, faults, and other operation and maintenance events and their physical resources; and flow relationships represent the allocation and responsibility associations of work orders and tasks among operation and maintenance organizations and personnel. Object relationship path constraints can be preset network topology, resource level, and association scope constraint rules, used to limit the retrieval scope of upstream and downstream related resources of abnormal resources, avoiding invalid related object retrieval and ensuring accurate location.

[0056] By configuring relationships to bind the basic ownership attributes of resource objects and operation and maintenance / organization objects; by establishing attachment relationships to establish the dependency association between physical resources and operation and maintenance events such as alarms and faults; and by realizing the linkage of rights and responsibilities between operation and maintenance work orders, handling tasks, operation and maintenance teams, and responsible persons through flow relationships, a holistic object relationship network of interconnected and bidirectionally searchable resource, operation and maintenance, and organization objects is ultimately formed.

[0057] The resource ontology stores all communication network physical resources and topology association data. Based on the object candidate identifiers and indicator types in the anomaly request structure, it accurately matches the target resource object directly corresponding to the anomaly within the resource ontology. Simultaneously, relying on preset object relationship path constraints, combined with network topology levels and device mounting link rules, it traces upstream associated resources and extends downstream associated resources to complete the full-link associated resources corresponding to the core anomaly object. For example, if the set of object candidate identifiers in the anomaly request structure points to a port P, determining port P as the target resource object, based on resource relationship path constraints, it completes the upstream completion of board B, device D, and equipment room R, and the downstream completion of link L, ultimately resulting in the resource object set {R, D, B, P, L}.

[0058] The operations and maintenance ontology stores all network operations and maintenance event data. Based on cross-ontology object relationships, it uses the located target resource object as an index to retrieve all operations and maintenance events bound to that resource during the abnormal period, thus obtaining the target operations and maintenance object. The retrieval scope includes, but is not limited to: alarm objects attached to the resource object, fault objects formed by merging alarms, work order objects generated by faults, and task objects split from work orders.

[0059] The organizational structure and responsibility mapping of the organization's storage network operation and maintenance, combined with the locked abnormal resource objects and related operation and maintenance event objects, accurately match the corresponding maintenance unit, responsible team, operation and maintenance position and specific responsible person responsible for abnormal handling through preset responsibility mapping, territorial division and resource ownership relationship, and complete the closed-loop positioning from "abnormal resource" to "handling subject", and clarify the ownership of abnormal operation and maintenance responsibility.

[0060] Integrate all location data, summarize core and upstream and downstream related resource objects, all related operation and maintenance objects, and organizational objects with corresponding rights and responsibilities, and simultaneously generate a complete set of object relationship paths to form a structured and comprehensive abnormal object location result.

[0061] According to the embodiments of this application, by constructing the association relationships among three types of entities—resources, operations and maintenance, and organizations—multi-level and multi-dimensional precise location of communication network anomalies is achieved. By supplementing upstream and downstream related resource objects, the topological impact range of the anomaly is fully covered; by linking and retrieving operations and maintenance objects such as alarms, faults, and work orders, the association dimensions of anomaly analysis are enriched; and by accurately matching operations and maintenance organizations with responsible personnel, the responsible entities for anomaly handling are clarified.

[0062] In one implementation, when the set of candidate object identifiers in the exception request structure corresponds to multiple resource objects, retrieving the target resource object in the resource body according to the exception request structure includes: Based on the applicable object constraints of the indicators in the ontology constraints, and combined with the indicator types of the abnormal request structure, the appropriate object level is selected. Within the scope of this adaptation object level, several candidate resource objects are selected based on the mounting relationship of the source system corresponding to the anomaly information; In the resource ontology, the object relationship path length between each candidate resource object and the actual point of action of the anomaly is calculated, and the candidate resource object with the shortest object relationship path length is taken as the target resource object.

[0063] In this embodiment, the source system mounting relationship refers to the binding relationship between each monitoring system, alarm system, and the network resources it manages and monitors, used to define the effective resource range corresponding to different data sources. The actual point of impact of an anomaly can refer to the finest-grained resource object directly mounted or collected by the anomaly information in the source system, serving as a reference point for calculating the path length. When precise location is not possible, the finest-grained object in the set of object candidate identifiers in the anomaly request structure is used as an approximation of the actual point of impact of the anomaly.

[0064] When the set of candidate object identifiers in the abnormal request structure corresponds to multiple possible resource objects, preliminary hierarchical filtering is performed based on preset ontology constraint rules. Different network performance indicators and anomaly types are only applicable to network resource objects at specific levels and cannot be adapted to all types and levels of resources. Pre-configure the applicable object constraints for indicators to clarify the range of legal resource object levels corresponding to various indicators. Read the indicator type in the abnormal request structure, match the corresponding applicable object constraints, filter out all resource object levels that are not compatible with the indicator type, and retain only the applicable object levels that can truly correspond to and carry the abnormal indicator, thus completing the first large-scale filtering from the resource level dimension.

[0065] Based on the already selected adaptation object level, a second-dimensional precise screening is conducted. Different monitoring and alarm systems have fixed device mounting ranges and monitoring jurisdictions, and can only collect and report abnormal data of the resources they mount and manage. There are no cross-system or cross-jurisdictional abnormal reports. According to the source system identifier in the abnormal request structure, the system's preset resource mounting relationship is matched, and resource objects that do not belong to the jurisdiction of the source system and are not mounted on that system are further eliminated in the adaptation object level, ultimately retaining highly relevant candidate resource objects.

[0066] The resource ontology stores complete network topology levels and object association paths. The object relationship path length of each candidate resource object relative to the actual point of action of the anomaly is calculated. For example, each topology jump between objects is counted as 1 unit path length. For example, in the case of computer room (0) - device (1) - board (2) - port (3), the path length of the port relative to the computer room is 3. When selecting the best candidate resource, the object with the smallest path value is selected. The path length represents the number of topology level jumps and object association jumps. The shorter the path length, the higher the correlation between the candidate object and the source of the anomaly and the closer the location is. The candidate resource object with the shortest path length is selected as the unique target resource object corresponding to this anomaly, thus completing the accurate location convergence in the multi-candidate scenario.

[0067] According to the embodiments of this application, a three-level progressive screening mechanism is constructed for complex scenarios with ambiguity in matching multiple candidate objects in network anomalies. This mechanism consists of hierarchical adaptation, system mounting constraints, and path optimization. Hierarchical constraints enable filtering of a wide range of invalid objects; system mounting relationships enable precise convergence of candidate objects; and shortest path optimization enables locking onto a unique target object. This progressive approach, with accuracy increasing at each level, significantly improves the accuracy and uniqueness of anomaly resource location in complex topologies and scenarios with multiple associated resources, thus avoiding anomaly object location deviations at the source.

[0068] To illustrate the abnormal object location process, consider the following abnormal request structure: Object candidate identifier set: Port object candidate; Indicator type: Optical power; Time window: 3 consecutive monitoring cycles; Condition item set: Continuous over-limit, Linked alarm.

[0069] First, based on the constraints of the applicable objects of the indicators, the optical power anomaly is preferentially attributed to either the port object or the link object. Then, based on the correspondence between candidate object identifiers and resource object identifiers, a specific port object is determined as the priority attribute object. Next, based on resource relationship path constraints, the associated board objects, device objects, data center objects, and link objects are completed. Then, based on alarm attachment relationships, the LOS alarm objects attached to the port object are located; based on fault association relationships, the corresponding fault objects are located; and based on work order flow relationships, the corresponding work order objects are located. Finally, based on responsibility mapping relationships, the maintenance unit, responsible team, position, and responsible person are identified.

[0070] In one implementation, generating a decision context based on the ontology constraints, using the exception request structure and the exception object location result, may include: Extract the original object type from the abnormal object location result and extract the original indicator type from the abnormal request structure; combine the indicator applicable object constraint in the ontology constraint to obtain the applicable object type and applicable indicator type respectively. Based on the action application condition constraints in the ontology constraints, the set of condition items and the abnormal values ​​in the abnormal request structure are converted into constraint expressions. The risk level is determined based on the actual object level corresponding to the target resource object, the object's relationship path, and the indicator type, time window, and set of condition items in the abnormal request structure. Based on the rule scope constraints in the ontology constraints and the risk level, a set of applicable handling actions is generated; The applicable object type, the applicable indicator type, the object relationship path, the time window, the constraint expression, the risk level, and the applicable set of actions are combined into the judgment context.

[0071] In this embodiment, the applicable object type can be a resource object type that has passed the indicator applicable object constraint verification and matches the current abnormal indicator in compliance. The applicable indicator type can be a valid indicator type that can be adapted to the located resource object after being filtered based on ontology constraints. The constraint expression can be a structured logical expression compiled from the original abnormal value and condition items according to a unified syntax.

[0072] The system extracts the original object types and their inter-object relationships from the anomaly location results. Simultaneously, it extracts the original indicator types, anomaly duration time windows, and various anomaly condition items from the standardized anomaly request structure, completing the extraction of basic raw data. It then invokes the indicator applicability constraints from the ontology constraints to perform compliance verification and adaptation filtering on the original object types and indicator types. Object types that do not match the current anomaly indicators and indicator types that cannot correspond to resource objects are eliminated. Finally, it selects the applicable object types and indicator types that meet the rule requirements.

[0073] The action application conditions and constraints pre-define standardized syntax rules corresponding to various abnormal conditions and indicator values. It reads information such as limit violations and linked alarms, along with abnormal values, from the set of condition items and compiles them into standardized constraint expressions that can be recognized by the machine, thus transforming fragmented text conditions into structured rule conditions. For example, the condition item "continuous limit violation" is converted into the constraint expression "number of continuous limit violation cycles ≥ N", where N is the number of windows in the time window; "linked alarm" is converted into "alarm type exists = X"; and multiple condition items are combined into a complete constraint expression using logical operators AND / OR.

[0074] Values ​​are taken from five dimensions: object level, indicator severity, scope of impact of anomaly, duration of anomaly, and additional associated conditions. The weight of data center / equipment / link / port is distinguished based on object level; the severity of exceeding limits is determined based on indicator type and anomaly value; the scope of anomaly impact is determined based on object relationship path; the duration of anomaly is calculated based on time window; and additional conditions such as linkage alarms and associated work orders are identified based on condition item set. After multi-factor weighted calculation, the risk level is divided into three levels: high, medium, and low. For example, a scoring method is used to determine the risk level: Object-level weight: Port = 5 points, Link = 4 points, Device = 2 points, Data Center = 1 point; Indicator severity: Exceeding the limit by less than 3dB is 1 point, 3-6dB is 2 points, and exceeding 6dB is 3 points; Scope of impact: Single object = 1 point, Link level = 2 points, Critical path level = 3 points, Multiple object association = 4 points; Duration of time: Single point of failure = 1 point, 2 consecutive monitoring windows = 2 points, 3 or more consecutive monitoring windows = 3 points; Additional conditions: 1 point is added for each item in the following categories: Linked alarms, accompanying error codes, or existing related work orders; The total score is the sum of the scores of the above five items: A total score ≥ 10 points indicates high risk, 5-9 points indicates medium risk, and ≤ 4 points indicates low risk.

[0075] The rules apply to a range of situations, which are limited to the boundaries of the appropriate handling solutions for different risk levels and object types. The calculated risk level is used as the main screening criterion. Handling methods that are not applicable are removed from the pre-set handling library, and a set of handling actions suitable for this anomaly is obtained. These actions may include options such as observation, review, dispatch, and escalation.

[0076] All the aforementioned structured data are aggregated, uniformly encapsulated and integrated to form a judgment context that carries object semantics, indicator semantics, relational semantics, constraints and pre-selected handling schemes, providing complete and standardized input data for subsequent rule judgment.

[0077] According to the embodiments of this application, the compliance and reliability of basic data are ensured by extracting valid fields that have been verified by constraints, and scattered abnormal conditions are compiled into standardized constraint expressions by using unified rules. The scientific nature of risk classification is improved by relying on multi-dimensional factors for comprehensive classification. In addition, compliant handling actions are screened by combining constraint boundaries. Finally, multiple types of key information are integrated to form a structured context, so that the subsequent handling rules are based on evidence, which significantly improves the standardization and accuracy of abnormal handling judgment.

[0078] In one implementation, the determination of the handling rules based on the determination context to obtain the exception handling result may include: Based on the judgment context, a local rule set is obtained by filtering from the preset rule set. The judgment context includes the applicable object type, applicable indicator type, object relationship path, time window, constraint expression, risk level and applicable disposal action set. The handling rules are executed within this local rule set to determine the exception handling result.

[0079] In this embodiment, a preset rule set stores all network anomaly handling rules across all operational scenarios. The set contains a large number of rules covering various resources, metrics, and risk scenarios. Using multi-dimensional information such as object type, metric type, risk level, and constraints carried in the judgment context as filtering indexes, redundant rules irrelevant to the current anomaly scenario are quickly removed from the full set of preset rules according to the rules' applicable scope constraints. Only rules suitable for the current anomaly attributes are retained, forming a streamlined local rule set. This achieves preliminary rule screening, narrowing the scope of subsequent rule calculations.

[0080] After rule simplification, the rules are matched and verified item by item within a limited set of local rules, using constraint expressions, associated paths, and additional conditions of the decision context. This compares whether all rule logical conditions are met, and outputs the corresponding action based on the matched rules. Finally, the final decision is determined from observation, review, dispatch suggestion, and escalation suggestion. In practical applications, rules can be preset with priority: escalation action > dispatch suggestion > review > observation. When multiple rules are matched simultaneously, only the highest priority action is retained, and similar conclusions are automatically merged without duplicate output.

[0081] According to the embodiments of this application, a two-level rule filtering architecture is adopted, which first performs coarse screening to narrow down the rules and then performs precise matching and judgment. First, the full set of rules is filtered on a large scale based on the judgment context to form local rules, which greatly reduces the amount of data to be traversed and matched in the subsequent rules and reduces the computational overhead.

[0082] In one implementation, the process of filtering from a preset set of rules based on the determination context to obtain a local set of rules may include: Based on the applicable object type and applicable indicator type in the judgment context, applicable rules are selected from the preset rule set to obtain the first rule subset; Based on the object relationship path in the judgment context, rules that do not meet the object relationship path requirements are removed from the first rule subset to obtain the second rule subset; Based on the time window in the judgment context, rules that do not meet the time window requirements are removed from the second rule subset to obtain the third rule subset; Based on the constraint expression in the decision context, rules that do not meet the constraint conditions are removed from the third rule subset to obtain the local rule set.

[0083] In this embodiment of the application, the preset rule set contains a massive number of processing rules corresponding to all categories of resources and all indicators. The applicable object type and applicable indicator type of the judgment context are used as the first round of screening conditions to quickly filter out the rules whose bound objects and indicators match the current anomaly, eliminate irrelevant rules whose object types and indicator types do not match at all, initially compress the rule range, and generate the first rule subset.

[0084] Different handling rules impose limitations on the topology links and object association ranges affected by the anomalies. Based on the object relationship path information stored in the judgment context, the constraints of each rule in the first rule subset on the topology association range are verified. Rules that do not match the link level and association range required by the rules with the actual object relationship paths are eliminated, and the second rule subset is obtained.

[0085] Various rules set judgment thresholds for the continuous monitoring period and duration of anomalies. Combined with the standardized time window parameters of the context, rules that do not match the required duration of anomalies with the actual anomaly monitoring period are filtered out, and the remaining compliant rules form a third rule subset.

[0086] The constraint expression integrates all abnormal limiting conditions such as the index exceeding the limit, linkage alarm, and additional working conditions. It compares the condition thresholds of the rules in the third rule subset with the constraint expression item by item, eliminates the remaining rules whose conditions cannot be matched, and finally converges to form a local rule set that is suitable for this abnormality.

[0087] According to the embodiments of this application, a four-layer progressive screening rule is adopted, consisting of object indicators, topology path, time period, and constraint conditions. The rule range is narrowed down layer by layer from coarse to fine. Compared with full rule traversal matching, this method not only filters out invalid and redundant rules layer by layer, continuously narrows the rule matching range, and reduces computational overhead, but also constrains the rule adaptation boundary from multiple dimensions, avoiding rule misselection due to the omission of a single screening condition. This further improves the accuracy of the local rule set and lays the foundation for accurate rule judgment and reliable processing results in the future.

[0088] By constructing a unified network relationship graph through three layers of ontology—resources, operations and maintenance, and organization—heterogeneous anomaly information is first structured and normalized. Then, the three-layer ontology is used to automatically trace related links, accurately locating specific devices, alarm information, and responsible parties, and generating standardized rule-based judgment contexts. Based on the context, local rule sets are dynamically filtered, and judgments are executed within a narrowed scope. Finally, traceable and actionable handling suggestions are output, achieving full-process automation from anomaly normalization, precise location, intelligent responsibility determination to automatic suggestions, ensuring the accuracy, consistency, and efficiency of network operation and maintenance decisions.

[0089] Figure 2 This is a schematic diagram of an application scenario provided for this application.

[0090] like Figure 2 As shown, Resource Ontology 201 includes physical resources of communication networks such as computer rooms, equipment, boards, ports, links, and circuits. It provides the hierarchical relationship and topological connection relationship of resource objects and is the basic data support for abnormal resource location and impact range analysis.

[0091] Operations and Maintenance Subject 202: Includes operations and maintenance event objects such as alarms, faults, work orders, tasks, inspection records, and maintenance actions. It provides the mapping relationship between resource objects and operations and maintenance events, the relationship between fault flow and work order association, and provides operations and maintenance dimension data for the entire link association of anomalies.

[0092] Organizational entity 203: Includes organizational objects such as geographical units, professional units, maintenance units, responsible teams, positions, and responsible persons, providing resource ownership, responsibility division, and job responsibility mapping relationships, and providing organizational dimension support for the identification of responsible entities for anomaly handling.

[0093] Ontology Constraint 204: The three types of ontology work together in the ontology constraint layer to form unified semantic constraint rules, including: object type constraints, index applicable object constraints, object relationship path constraints, action applicable condition constraints, and rule applicable scope constraints. These constraint rules transform the static data of the three types of ontology into executable logical conditions, providing a unified verification and screening standard for subsequent stages.

[0094] Anomaly object location result 205: Based on ontology constraints, multi-dimensional correlation and location of resource, operation and maintenance, and organizational objects are completed, generating a complete location result that includes a set of resource objects, a set of operation and maintenance objects, a set of organizational objects, and a set of object relationship paths.

[0095] Judgment Context 206: Based on ontology constraints, the positioning results and abnormal requests are adapted, verified, conditionally compiled, and risk-rated to generate a standardized judgment context that includes the applicable object type, applicable indicator type, time window, constraint expression, and risk level.

[0096] Local rule determination 207: Based on the filtering criteria such as path, time, and conditions provided by the ontology constraints, the full set of rules is filtered at multiple levels to obtain a set of local rules that are suitable for the current abnormal scenario, providing a reliable basis for the final processing result output.

[0097] Figure 3 A schematic diagram illustrating another application scenario provided in this application.

[0098] like Figure 3 As shown, the judgment context 301 provides complete structured information on anomalies, including applicable object type, applicable indicator type, object relationship path, time window, and constraint expression, providing a unified comparison basis for rule filtering.

[0099] Preset rule set 302: Stores a complete set of exception handling rules. Each rule includes fields such as applicable object type, applicable indicator type, path constraint, time window constraint, conditional expression, handling action, priority, and risk level, defining the handling logic for different scenarios.

[0100] A five-level progressive filtering method is adopted, gradually narrowing the scope of rules from coarse to fine. Among them, the applicable object type filter 303: removes rules whose applicable objects do not match the current abnormal object; the applicable indicator type filter 304: removes rules whose applicable indicators do not match the current abnormal indicator; the object relationship path filter 305: removes rules whose rule path constraints do not match the actual topology path; the time window filter 306: removes rules whose rule requirements for the duration of the abnormality do not match the actual time window; and the constraint expression filter 307: removes rules whose rule condition expressions do not match the current abnormal constraint conditions.

[0101] Local rule set 308: After the above filtering, a local rule set that is adapted to the current abnormal scenario is obtained.

[0102] Rule Execution and Output 309: Based on the finalized target rules, execute the corresponding handling logic and output standardized handling results, including four categories: observation, review, dispatch suggestion, and escalation handling suggestion, providing clear and actionable guidance for operations and maintenance personnel. Simultaneously, if multiple rules in a local rule set are simultaneously triggered, handle them according to a preset strategy, prioritizing the rule with the highest priority or risk level, and merging similar handling actions to avoid duplicate instructions.

[0103] Figure 4 This is a schematic diagram illustrating yet another application scenario provided by this application.

[0104] To facilitate understanding, let's take the application scenario of continuous exceeding of optical power limits at the data center port as an example, such as... Figure 4 As shown, the specific process is as follows: S410: Receive abnormal information. The abnormal information received from the monitoring platform is: the optical power monitoring value of a certain port exceeds the set threshold for three consecutive monitoring windows, and is accompanied by a trigger alarm.

[0105] S420: Normalizes abnormal information to generate a standardized abnormal request structure. It sequentially standardizes object identifier, metric, time, and additional conditions, resulting in the following abnormal request structure: abnormal type is performance metric abnormality, object candidate identifier is the corresponding port identifier, metric type is optical power, time window is three consecutive monitoring windows, and the condition set includes continuous limit exceeding and linked alarms.

[0106] S430: Conduct full-dimensional object localization based on semantic models and ontology constraints. First, relying on the resource ontology, it retrieves and completes the associated resource objects, successively obtaining port objects, board objects, device objects, data center objects, and docking link objects; then, it retrieves the operation and maintenance ontology through preset object association relationships, matching the associated alarm objects, associated work orders, or operation and maintenance task objects corresponding to this anomaly; finally, relying on the authority and responsibility mapping relationship of the organization ontology, it locates the local unit, maintenance unit, and responsible team corresponding to the resource, and summarizes all object information to generate the anomaly object localization result.

[0107] S440: Integrates the abnormal request structure and abnormal object location results, and generates a judgment context by combining various ontology constraints. The generated judgment context includes: applicable object type is port, link; applicable indicator type is optical power; object relationship path is data center—equipment—board—port—link; time window is three consecutive monitoring windows; constraint expression is compiled from continuous over-limit and linkage alarm conditions; the risk level is comprehensively calculated by combining resource level, abnormal impact range, duration, and additional linkage conditions, and a subset of optional handling actions is obtained by filtering according to the rule's applicable scope constraints. All the above data are uniformly encapsulated to form a complete judgment context.

[0108] S450: Based on the judgment context, hierarchical filtering rules are used to complete the handling judgment. Using the object, indicator, topology path, time, and constraints carried by the judgment context as filtering elements, irrelevant rules are eliminated layer by layer from the full preset rule base, converging to obtain a local rule set. Then, rule conditions are precisely matched within the local rules. Different abnormal operating conditions correspond to different handling conclusions: if there is only a single-cycle indicator fluctuation without continuous limit violations or linked alarms, observation and handling are output; if there are three consecutive cycles of limit violations but no linked alarms and the risk is low, review and handling are output; if there are three consecutive cycles of limit violations accompanied by linked alarms, a dispatch suggestion is output; if the anomaly occurs in a critical backbone link, affects core business paths, and is classified as high risk, an escalation handling suggestion is output.

[0109] S460: Outputs the final handling result and judgment basis. The final output handling result is a dispatch suggestion, and the judgment basis is: the source of the anomaly is the link port, the optical power exceeds the limit for three consecutive monitoring windows, the entire link object path has been located, the anomaly is accompanied by a linkage alarm, the comprehensive assessment is medium to high risk, and the dispatch handling rule is matched.

[0110] By standardizing the fragmented raw anomaly data into a unified anomaly request structure, multi-dimensional object association and positioning are achieved based on the ontology semantic model, hierarchical rule filtering and intelligent judgment are completed based on the standardized judgment context, and differentiated handling conclusions are output in a standardized manner, thus realizing intelligent handling of communication network anomalies throughout the entire process.

[0111] Figure 5This application provides a schematic diagram of a communication network anomaly handling device, which may include: The acquisition module 510 is used to acquire abnormal information of the communication network; The processing module 520 is used to convert the abnormal information into a corresponding abnormal request structure using normalization processing. The abnormal request structure includes an abnormal type, a set of candidate object identifiers, an indicator type, an abnormal value, a time window, a set of condition items, and a source system identifier. The localization module 530 is used to perform ontology-driven object localization on the abnormal request structure based on the semantic model under ontology constraints, and generate abnormal object localization results. The semantic model includes resource ontology, operation and maintenance ontology, and organization ontology. The abnormal object localization results include a set of resource objects, a set of operation and maintenance objects, a set of organization objects, and a set of object relationship paths. The ontology constraints include object type constraints, indicator applicable object constraints, object relationship path constraints, action applicable condition constraints, and rule applicable scope constraints. The generation module 540 is used to generate a judgment context based on the abnormal request structure and the abnormal object location result, using the ontology constraints. The judgment context is used to carry the object semantics, indicator semantics, relational semantics and constraint conditions required for rule judgment. The judgment module 550 is used to perform the judgment of the handling rules based on the judgment context and obtain the abnormal handling result.

[0112] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown in the figure, a communication network anomaly handling device 600 provided in this application embodiment includes a memory 630, a processor 610 and a computer program 620 stored in the memory. The processor 610 executes the computer program 620 to implement the communication network anomaly handling method described in any of the above embodiments.

[0113] This application provides a communication network anomaly handling device, which may include a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the communication network anomaly handling method described in any of the above embodiments.

[0114] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the communication network anomaly handling method described in any of the above embodiments.

[0115] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0116] Obviously, those skilled in the art should understand that the various units or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device, or fabricating them separately as individual integrated circuit modules, or fabricating multiple modules or steps into a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0117] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for handling communication network anomalies, characterized in that, include: Obtain abnormal information from the communication network; The abnormal information is converted into a corresponding abnormal request structure using normalization processing. The abnormal request structure includes an abnormal type, a set of candidate object identifiers, an indicator type, an abnormal value, a time window, a set of condition items, and a source system identifier. Under ontology constraints, ontology-driven object localization is performed on the abnormal request structure based on the semantic model to generate abnormal object localization results. The semantic model includes a resource ontology, an operation and maintenance ontology, and an organization ontology. The abnormal object localization results include a set of resource objects, a set of operation and maintenance objects, a set of organization objects, and a set of object relationship paths. The ontology constraints include object type constraints, indicator applicable object constraints, object relationship path constraints, action applicable condition constraints, and rule applicable scope constraints. Based on the abnormal request structure and the abnormal object location result, a decision context is generated using the ontology constraints, wherein the decision context is used to carry the object semantics, indicator semantics, relational semantics and constraint conditions required for rule determination; Based on the judgment context, the handling rules are executed to determine the exception handling result.

2. The method according to claim 1, characterized in that, Under ontology constraints, the ontology-driven object localization of the abnormal request structure based on the semantic model, generating abnormal object localization results, includes: According to the abnormal request structure, the target resource object is retrieved in the resource ontology, and the upstream and downstream resource objects associated with the target resource object are completed according to the object relationship path constraints; Using object relationships, the target operation and maintenance object corresponding to the target resource object is retrieved in the operation and maintenance ontology. The object relationships are pre-established between resource objects, operation and maintenance objects, and organization objects. The operation and maintenance objects include alarm objects, fault objects, work order objects, and task objects. Based on the target resource object and the target operation and maintenance object, the target organization object is retrieved in the organization ontology using the object relationship. The organization object includes maintenance unit, responsible team, position and responsible person. Based on the target resource object, the target operation and maintenance object, and the target organization object, an anomaly object location result is generated.

3. The method according to claim 2, characterized in that, When the set of candidate object identifiers in the abnormal request structure corresponds to multiple resource objects, the step of retrieving the target resource object in the resource body according to the abnormal request structure includes: Based on the applicable object constraints of the indicators in the ontology constraints, and combined with the indicator types of the abnormal request structure, the adaptive object level is selected. Within the scope of the adaptation object level, several candidate resource objects are selected based on the mounting relationship of the source system corresponding to the anomaly information; In the resource ontology, the object relationship path length between each candidate resource object and the actual point of action of the anomaly is calculated, and the candidate resource object with the shortest object relationship path length is taken as the target resource object.

4. The method according to claim 3, characterized in that, The step of generating a determination context based on the abnormal request structure and the abnormal object location result, using the ontology constraints, includes: Extract the original object type from the abnormal object location result and extract the original indicator type from the abnormal request structure; combine the indicator applicable object constraint in the ontology constraint to obtain the applicable object type and applicable indicator type respectively. Based on the action application condition constraints in the ontology constraints, the set of condition items and the abnormal values ​​in the abnormal request structure are converted into constraint expressions; The risk level is determined based on the actual object level corresponding to the target resource object, the object relationship path, and the indicator type, time window, and set of condition items in the abnormal request structure. Based on the rule scope constraints in the ontology constraints and the risk level, a set of applicable handling actions is generated; The applicable object type, the applicable indicator type, the object relationship path, the time window, the constraint expression, the risk level, and the applicable set of actions are combined into the determination context.

5. The method according to claim 1, characterized in that, The step of performing the handling rule determination based on the determination context to obtain the exception handling result includes: Based on the judgment context, a local rule set is obtained by filtering from the preset rule set. The judgment context includes the applicable object type, applicable indicator type, object relationship path, time window, constraint expression, risk level and applicable disposal action set. The handling rules are executed within the local rule set to determine the anomaly handling result.

6. The method according to claim 5, characterized in that, The step of filtering from the preset rule set based on the determination context to obtain the local rule set includes: Based on the applicable object type and applicable indicator type in the determination context, applicable rules are filtered from the preset rule set to obtain a first rule subset; Based on the object relationship path in the judgment context, rules that do not meet the object relationship path requirements are removed from the first rule subset to obtain the second rule subset; Based on the time window in the judgment context, rules that do not meet the time window requirements are removed from the second rule subset to obtain the third rule subset; Based on the constraint expression in the determination context, rules that do not meet the constraint conditions are removed from the third rule subset to obtain the local rule set.

7. A communication network anomaly handling device, characterized in that, include: The acquisition module is used to acquire abnormal information from the communication network. The processing module is used to convert the abnormal information into a corresponding abnormal request structure using normalization processing. The abnormal request structure includes an abnormal type, a set of candidate object identifiers, an indicator type, an abnormal value, a time window, a set of condition items, and a source system identifier. The localization module is used to perform ontology-driven object localization on the abnormal request structure based on a semantic model under ontology constraints, and generate abnormal object localization results. The semantic model includes a resource ontology, an operation and maintenance ontology, and an organization ontology. The abnormal object localization results include a set of resource objects, a set of operation and maintenance objects, a set of organization objects, and a set of object relationship paths. The ontology constraints include object type constraints, indicator applicable object constraints, object relationship path constraints, action applicable condition constraints, and rule applicable scope constraints. The generation module is used to generate a judgment context based on the abnormal request structure and the abnormal object location result, using the ontology constraints. The judgment context is used to carry the object semantics, indicator semantics, relational semantics and constraint conditions required for rule judgment. The determination module is used to perform a determination based on the determination context and the handling rules to obtain the abnormal handling result.

8. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any one of claims 1-6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.

Images