WO2020044352A1 - Génération de règles pour données de réseau - Google Patents

Génération de règles pour données de réseau Download PDF

Info

Publication number
WO2020044352A1
WO2020044352A1 PCT/IN2018/050550 IN2018050550W WO2020044352A1 WO 2020044352 A1 WO2020044352 A1 WO 2020044352A1 IN 2018050550 W IN2018050550 W IN 2018050550W WO 2020044352 A1 WO2020044352 A1 WO 2020044352A1
Authority
WO
WIPO (PCT)
Prior art keywords
time series
series data
network
rule
data
Prior art date
Application number
PCT/IN2018/050550
Other languages
English (en)
Inventor
Mahesh Babu JAYARAMAN
Sandhya BASKARAN
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/IN2018/050550 priority Critical patent/WO2020044352A1/fr
Priority to EP18932045.0A priority patent/EP3844921A1/fr
Publication of WO2020044352A1 publication Critical patent/WO2020044352A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications

Definitions

  • the present disclosure relates to method and apparatus for generating a rule for the grouping of network data into incidents.
  • the present disclosure also relates to a method for processing network data and to a computer program product configured to carry out methods for generating a rule and processing network data.
  • Incident management in a network involves the processing of network data to identify incidents taking place within the network, enabling appropriate action to be taken to resolve these incidents. Incident management is conducted in some form in a wide range of networks, including but not limited to telecommunications networks, Internet of Things (IoT) networks, Data Centers, Local Area Networks (LANs), Wide Area Networks (WANs) etc.
  • IoT Internet of Things
  • LANs Local Area Networks
  • WANs Wide Area Networks
  • Networks of the type discussed above typically comprise complex topologies of nodes which may be interconnected via a range of different technologies, including for example Ethernet, Wireless Radio, Optical, Microwave etc.
  • Nodes may be grouped into different network domains, including, in a telecommunications example, a Radio Access Network (RAN), Transport Network and Core Network.
  • Alarms and performance events are generated in all parts of a network, at physical and virtual nodes.
  • a traditional approach to incident management is to collect alarms as part of a fault management framework, and performance events as part of a performance management framework, and to process the collected alarms and events using methods specific to the different domains and based on extensive domain knowledge. The processing of the gathered alarms and performance events allows for the generation of insights about the operation of the network, facilitating network management.
  • a rule for the processing of network event data is a code-segment that identifies a set of alarms generated by various nodes, which may belong to different domains in a network. It will be appreciated that a single network fault may provoke multiple alarms from different nodes in different domains. Thus for example a single failed link may impact multiple nodes, resulting in missed heartbeat messages and consequently several alarms from different nodes expecting to be able to send or receive such messages. Additionally, in the event of a failure of an underlay service, a dependent overlay service may also be affected, meaning nodes impacted by both the underlay and overlay service failures may all generate alarms.
  • a fault in a single physical node may lead to alarms in multiple logical functions, and a fault in a lower layer of the network, such as L2 or L3, will give rise to a reflected fault in higher layers, such as L4 and higher.
  • a network element, node, function or service deployed in a network generates an alarm when it observes that its dependent, peering or partner function, node or service entity is not responding, not exhibiting expected behaviour or not providing a desired outcome. Correlation of multiple alarms resulting from the same underlying fault into an incident allows for efficient identification of the underlying fault and consequently facilitates its resolution.
  • One existing method for grouping related alarms to form an incident is to manually identify a set of alarms for grouping based on operational knowledge or domain knowledge.
  • the grouped alarms sometimes called a pseudo alarm as they represent a group of real- alarms, may then be subject to further analysis to identify root causes and appropriate actions for resolution.
  • WO 2017/157438 discloses a statistical rule generation that performs pairwise correlation of alarms.
  • the method of WO 2017/157438 requires extensive computational power and is sensitive to the order in which faults are generated.
  • alarm and event data may be aggregated at various sub layers and may be transported via intermediate systems before reaching a central repository, meaning that alarms cannot be guaranteed to be received in the order in which they were generated.
  • Telecommunications networks in particular are multi-domain (core, backhaul, aggregation, backbone, RAN etc.), multi-layer, multi-vendor and multi-technology (radio, optical, microwave, Ethernet etc.). Telecommunications networks are also multi-use with for example multiple generations of standards coexisting to service voice and data traffic for a wide range of use cases. Network structure is convoluted, with multiple different architecture possibilities. Manual generation of cross-domain rules that capture relationships between the many different layers, actors, etc. is extremely complex.
  • cross domain rules may seek to handle alarms from multiple heterogeneous systems with different alarm structures, syntax etc. and which may overlap in time.
  • a method for generating a rule for the grouping of network data into incidents comprises obtaining time series data representing operation of the network, the time series data comprising notifications of events occurring within the network.
  • the method further comprises dividing the obtained time series data into segments, a segment comprising data representing operation of a part of the network.
  • the operation of the network may be represented via network performance and/or any other network event.
  • the method further comprises, for a segment of time series data, normalising a structure of the time series data into time series data items, a time series data item comprising a property of a notified event, and grouping the normalised time series data items into transactions, wherein a transaction comprises a group of time series data items occurring within a time window.
  • the method further comprises, for a segment of time series data, identifying a pattern of time series data items in the transactions using a machine learning process, a pattern comprising a set of data items that are correlated, and translating the identified pattern into a rule, wherein the rule comprises a specification of events to be grouped into a network incident, a specified event being identified by a data item comprising a property of the specified event.
  • the network may comprise any type of network comprising two or more communicating network nodes.
  • a network may be a telecommunications network such as a 3 GPP network, an IoT network, a data center, a Local Area Network (LAN), a Wide Area Network (WAN) etc.
  • the steps of the method may be repeated to generate multiple rules for one or more segments, in some examples for each segment, of the data.
  • multiple patterns may be identified and one, some or all of those patterns may be translated into rules.
  • the notified events may comprise at least one of fault alarms, performance alarms, performance events and/or environment events.
  • a fault alarm may be generated by a network node or function in the event of a suspected fault such as a missed heartbeat message, a lost connection etc.
  • a performance alarm may be generated by a network node or function when a monitored performance parameter attains a threshold. Performance alarms may in some examples not be distinguished within alarm data.
  • a performance event may comprise a periodic or scheduled notification of a monitored performance parameter.
  • An environment event may comprise a notification of a condition in an environment in which the network operates, such as for example a temperature, precipitation or other sensor notification from an environment in which one or more network nodes is deployed.
  • the data may be historical data obtained from a network repository for such data such as a Network Operations Centre, Operations and Management node, etc.
  • the network repository may comprise a data storage location such as a data lake or data warehouse according to different installation or deployment scenarios.
  • dividing the obtained time series data into segments may comprise clustering network nodes, and for individual clusters of nodes, identifying a level of network partitioning at which a percentage of nodes within the cluster belong to the same part of the network, the percentage being above a threshold level.
  • Dividing the obtained time series data into segments may further comprise selecting a level of network partitioning for the time series data on the basis of the levels identified for individual clusters of nodes, and grouping the obtained time series data such that notifications of events received from nodes in the same part of the network, according to the selected level of network partitioning, belong to the same data segment.
  • dividing the obtained time series data into segments may further comprise selecting a level of network partitioning for the time series data on the basis of network layers or some form of logical grouping based for example on network topology or network service provision.
  • the levels of network partitioning may be based upon a network management model, such that parts of the network may correspond to groups of network nodes which may be collectively managed. Examples of such groups may include managed environments such as rooms, floors, buildings etc. within an IoT deployment, nodes, sites or regions within a telecommunications network, districts or cities within a WAN etc. It will be appreciated that such partitioning generally corresponds to a geographical grouping of network nodes, and the levels of network partitioning may in some examples correspond to geographical divisions of the network. According to examples of the present disclosure, the partitioning of the network may be such that a single part of the network spans multiple logical network domains.
  • a partitioning of a telecommunications network may include elements of a Radio Access Network (RAN), transport network and core network within a single network part.
  • RAN Radio Access Network
  • Each of the included RAN, transport and core network nodes may service traffic originating within the region on which the network part is based.
  • clustering network nodes may comprise clustering network nodes according to at least one network node property selected from physical node location, topology relation, and/or node context.
  • clustering nodes according to their physical location may initially comprise mapping network nodes to their physical location.
  • the node context may comprise for example an identifier such as a room identifier for an IoT sensor or a name or type of data transmitted by a node.
  • dividing the obtained time series data into segments may further comprise obtaining metadata describing a physical network deployment, and obtaining a context radius for use in clustering of the network nodes.
  • the context radius may be provided by a network operator or domain expert.
  • the context radius may in some examples be a geographical radius based on physical node location, but may alternatively comprise a functional radius, such as a coverage zone for a telecommunications network node, a sensitivity radius for an environment sensor etc.
  • the coverage zone of the telecommunications node may correspond to the physical coverage zone or cell of a RAN node, or to a core network node coverage zone, encompassing multiple RAN cells from which traffic is directed through the core network node.
  • the telecommunications node itself may therefore be physically located within the coverage zone or may be located outside the coverage zone, for example in the case of a core network node which may manage traffic, mobility etc. for user equipments in a geographic location which is remote from the physical location of the core network node, particularly in the case of cloud based core networks.
  • normalising a structure of the time series data into time series data items may comprise obtaining metadata describing features of notified events to be included in data items, a feature comprising at least one of a property of an event or a resource associated with an event, obtaining a rule template specifying a data structure for data items, and for notified events in the time series data, generating a data item comprising at least a property of the event in accordance with the obtained metadata, and associating the generated data item with a time stamp associated with the event.
  • normalising a structure of the time series data into time series data items may allow input data from different domains to be recast into a neutral structure such that disparate data structures or data sets in their original forms may be converted to the neutral structure and referred to as items for further processing.
  • the neutral structure may be specified in a rule template and may comprise a property of an event.
  • normalising a structure of time series data into time series data items may further comprise, for a notified event in the time series data comprising a plurality of features described in the obtained metadata, generating a data item for each of the features described in the obtained metadata, and associating the generated data items with a time stamp associated with the event.
  • multiple items may be generated from a single event, should the event comprise multiple properties or resources specified in the metadata for inclusion in data items.
  • all of the generated data items are associated with the same time stamp corresponding to the event from which they were generated.
  • the metadata may specify that all features of all events be itemised, or may specify particular features of interest. Such features of interest may be specified by a network operator or domain expert, or may be generated as part of the method as discussed below.
  • generating a data item comprising at least a property of the event in accordance with the obtained metadata may comprise combining the property of the event with a resource associated with the event.
  • generating a data item comprising at least a property of the event in accordance with the obtained metadata may comprise encoding the property of the event in a data structure specified in the obtained rule template.
  • obtaining metadata describing features of notified events to be included in data items may comprise generating the metadata by conducting component analysis on obtained time series data to identify event features for itemisation, and describing the identified event features in metadata.
  • the event features for itemisation may be identified in the component analysis as those features having an importance above a certain threshold measure, or those features appearing most often amongst different events.
  • existing algorithms such as principal component analysis (PCA) may be used to identify event features for itemisation.
  • PCA principal component analysis
  • generating the metadata may further comprise, for identified features represented as a value within a continuous range, clustering the values of the identified features in the obtained time series data, assigning identifiers to the clusters, generating a mapping to convert values within the continuous range to one of the cluster identifiers, and describing the mapping in metadata.
  • generating a data item comprising at least a property of the event in accordance with the obtained metadata may comprise, for properties represented as a value within a continuous range, mapping the value of the property to a cluster identifier in accordance with the mapping described in the metadata, and encoding the cluster identifier in a data structure specified in the obtained rule template.
  • the process of generating metadata may be carried out for individual event types, such as for particular performance event types, environmental event types etc.
  • grouping the normalised time series data items into transactions may comprise obtaining a time window, and grouping time series data items occurring within the same time window into a transaction.
  • the time window may be a sliding window or a tumbling window and may in some examples be specified by a network operator or domain expert.
  • obtaining a time window may comprise obtaining historical problem tracking records, identifying time windows within which the events in the problem tracking records occurred, and selecting as the obtained time window one of the identified time windows.
  • the historical problem tracking records may in some examples be trouble tickets, for example as described in RFC 1297, among others.
  • the time window may be selected as the time window that would encompass a proportion of the obtained historical records that is above a threshold value, an average time window, a highest distribution time window, etc.
  • identifying a pattern of time series data items in the transactions using a machine learning process may comprise monitoring at least one of resource requirements or time requirements of the machine learning process, and adapting at least one parameter of the machine learning process in accordance with the monitored requirements.
  • the parameter may in some examples be a threshold used by the machine learning process.
  • a threshold used by the machine learning process may be adjusted so as to reduce the resource requirements (time, processing power, memory etc.) of the machine learning process.
  • adapting of parameters may take place if thresholds for resource or time requirements are exceeded, to reduce the resources (memory or computational) or time required to complete the identification of one or more patterns.
  • translating the identified pattern into a rule may comprise listing the correlated data items of the pattern in a structure consistent with a rule template.
  • the method may further comprise predicting an amount of time to generate a new rule, and, if the predicted time exceeds an acceptability threshold, performing at least one of generating a rule for only a subset of segments and/or generating a rule for a subset of event generating entities.
  • the subset of event generating entities may share a contextual or logical link.
  • the context for the link may be geographical and/or functional. Examples may include all entities in a room, all entities supplied with power by a given electrical power supply, all entities connected to the same ring main, all entities serving wireless devices in a given cell or group of cells etc.
  • the subset of segments and/or subset of event generating entities may have experienced network changes rendering previously generated rules obsolete.
  • a method for processing network data comprising obtaining online time series data representing operation of the network, the time series data comprising notifications of events occurring within the network, and obtaining a rule for the grouping of network data into incidents, the rule comprising a specification of events to be grouped into a network incident, a specified event being identified by a data item comprising a property of the specified event.
  • the method further comprises obtaining a time window, normalising a structure of the time series data into time series data items, a time series data item comprising a property of a notified event and comparing the normalised data items to the specification of the rule and the obtained time window.
  • the method further comprises, if, within the normalised data items, a set of data items exists that matches exactly to the data items in the specification of the rule and occurs within the obtained time window, then grouping the events corresponding to the data items of the set as a detected incident.
  • an exact match may require that every data item present in the specification of the rule also be present in the set.
  • an event corresponding to a data item may comprise the event form which the item was generated, that is the event having the property that is comprised within the data item.
  • the method may further comprise, if, within the normalised data items, a set of data items exists that partially matches to the data items in the specification of the rule and occurs within the obtained time window, then grouping the events corresponding to the data items of the set as a predicted incident.
  • a partial match may requires that at least a threshold percentage of data items present in the specification of the rule also be present in the set.
  • obtaining a rule for the grouping of network data into incidents may comprise obtaining a rule generated according to a method according to any one of the preceding aspects or examples of the present disclosure.
  • the method may further comprise obtaining metadata describing features of notified events applicable to the obtained rule.
  • normalising a structure of the time series data into time series data items may comprise generating time series data items corresponding to features specified in the metadata.
  • time series data items for features of the notified events that do not appear in the obtained metadata may not be generated.
  • obtaining a time window may comprise obtaining the time window used for generating transactions during generation of the rule.
  • obtaining metadata describing features of notified events applicable to the obtained rule may comprise obtaining the metadata used for normalising time series data during generation of the rule.
  • a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any one of the preceding aspects and/or examples of the present disclosure.
  • a carrier containing a computer program according to the preceding aspect of the present disclosure wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.
  • a computer program product comprising non transitory computer readable media having stored thereon a computer program according to a preceding aspect of the present disclosure.
  • apparatus for generating a rule for the grouping of network data into incidents.
  • the apparatus comprises a processor and a memory, the memory containing instructions executable by the processor such that the apparatus is operable to obtain time series data representing operation of the network, the time series data comprising notifications of events occurring within the network and divide the obtained time series data into segments, a segment comprising data representing operation of a part of the network.
  • the apparatus is further operable, for a segment of time series data, to normalise a structure of the time series data into time series data items, a time series data item comprising a property of a notified event, group the normalised time series data items into transactions, wherein a transaction comprises a group of time series data items occurring within a time window and identify a pattern of time series data items in the transactions using a machine learning process, a pattern comprising a set of data items that are correlated.
  • the apparatus is further operable to translate the identified pattern into a rule, wherein the rule comprises a specification of events to be grouped into a network incident, a specified event being identified by a data item comprising a property of the specified event.
  • the apparatus may be further operable to carry out a method in accordance with any one of the preceding aspects or examples of the present disclosure.
  • apparatus for generating a rule for the grouping of network data into incidents.
  • the apparatus is adapted to obtain time series data representing operation of the network, the time series data comprising notifications of events occurring within the network, and divide the obtained time series data into segments, a segment comprising data representing operation of a part of the network.
  • the operation of the network may be represented via network performance and/or any other network event.
  • the apparatus is further adapted, for a segment of time series data, to normalise a structure of the time series data into time series data items, a time series data item comprising a property of a notified event, group the normalised time series data items into transactions, wherein a transaction comprises a group of time series data items occurring within a time window and identify a pattern of time series data items in the transactions using a machine learning process, a pattern comprising a set of data items that are correlated.
  • the apparatus is further adapted to translate the identified pattern into a rule, wherein the rule comprises a specification of events to be grouped into a network incident, a specified event being identified by a data item comprising a property of the specified event.
  • the apparatus may be further adapted to carry out a method in accordance with any one of the preceding aspects or examples of the present disclosure.
  • the apparatus for generating a rule for the grouping of network data into incidents.
  • the apparatus comprises an input module for obtaining time series data representing operation of the network, the time series data comprising notifications of events occurring within the network, and a segmenter for dividing the obtained time series data into segments, a segment comprising data representing operation of a part of the network.
  • the operation of the network may be represented via network performance and/or any other network event.
  • the apparatus further comprises an itemiser for normalising a structure of the time series data in a segment into time series data items, a time series data item comprising a property of a notified event, and a transactioner for grouping the normalised time series data items of a segment into transactions, wherein a transaction comprises a group of time series data items occurring within a time window.
  • the apparatus further comprises a pattern mining engine for identifying a pattern of time series data items in the transactions of a segment using a machine learning process, a pattern comprising a set of data items that are correlated, and a rule translator for translating the identified pattern into a rule, wherein the rule comprises a specification of events to be grouped into a network incident, a specified event being identified by a data item comprising a property of the specified event.
  • Figure 1 is a flow chart illustrating process steps in a method for generating a rule for the grouping of network data
  • Figures 2a to 2d are flow charts illustrating process steps in another example of a method for generating a rule for the grouping of network data
  • Figure 3 is a flow chart illustrating process steps in a method for processing network data
  • Figure 4 is a block diagram illustrating functional units in an apparatus
  • Figure 5 is a block diagram illustrating functional units in another example of apparatus
  • Figure 6 is a representation of a system architecture
  • Figure 7 is an illustration of an example Rule Generation Flow
  • Figure 8 is a sequence flow diagram illustrating interactions between functional units of the Rule Generation Flow
  • Figure 9 is a block diagram illustrating functional units within a Segmenter
  • Figure 10 is a sequence flow diagram illustrating interactions between functional units of a Segmenter
  • Figure 11 s a block diagram illustrating an Itemizer
  • Figure 12 is a sequence flow diagram illustrating actions of the Itemizer
  • Figure 13 is a block diagram illustrating a Pseudo Event Encoder
  • Figure 14 is a sequence flow diagram illustrating actions of the Pseudo Event Encoder
  • Figure 15 is a block diagram illustrating an Automatic Event Encoder
  • Figure 16 is a sequence flow diagram illustrating actions of the Automatic Event Encoder
  • Figure 17 is a block diagram illustrating a Rule Generation Engine
  • Figure 18 is a sequence flow diagram illustrating interactions between functional units of a Rule Generation Engine
  • Figure 19 is a block diagram illustrating a Transactionizer
  • Figure 20 is a block diagram illustrating learning of a Time Window
  • Figure 21 is a block diagram illustrating a Pattern mining Engine
  • Figure 22 is a block diagram illustrating a Rule Refresher
  • Figure 23 is a block diagram illustrating a Rule Interpreter
  • Figure 24 is a representation of Alarm History data
  • Figure 25 is a block diagram illustrating a telecommunications network
  • Figure 26 is a process flow for the example telecommunications network of Figure 25; and Figure 27 is a block diagram of an IoT network.
  • aspects of the present disclosure provide a method for generating a rule for the grouping of network data and a method for processing network data using a rule. Aspects of the present disclosure provide an automated solution to the generation of a rule for the grouping of network data, according to which time series network data is segmented before further analysis, this segmentation avoiding the generation of false positives from incorrectly correlated data. For segments of network data, examples of the disclosed method then normalise a structure of the network data, allowing for processing of data from different datasets, heterogeneous systems etc. The data in its normalised structure is then grouped into transactions and subject to pattern identification, before an identified pattern is translated into a rule for the grouping of network data.
  • Examples of the method for processing network data include the steps of normalising a structure of online time series network data and comparing the normalised data to a rule. An exact match between normalised online data and rule, within an obtained time window, signifies that the normalised data should be grouped into an incident.
  • Figure 1 is a flow chart illustrating process steps in a method 100 for generating a rule for the grouping of network data into incidents.
  • the method comprises obtaining time series data representing operation of the network, the time series data comprising notifications of events occurring within the network.
  • the method then comprises, in step 120, dividing the obtained time series data into segments, a segment comprising data representing operation of a part of the network.
  • the operation of the network may be represented via network performance and/or any other network event.
  • Subsequent method steps are conducted for a segment of time series data, and may be conducted for a single segment, multiple segments or all segments of time series data.
  • the method comprises normalising a structure of the time series data into time series data items, a time series data item comprising a property of a notified event.
  • the method comprises grouping the normalised time series data items into transactions, wherein a transaction comprises a group of time series data items occurring within a time window.
  • the method comprises identifying a pattern of time series data items in the transactions using a machine learning process, a pattern comprising a set of data items that are correlated.
  • the method comprises translating the identified pattern into a rule, wherein the rule comprises a specification of events to be grouped into a network incident, a specified event being identified by a data item comprising a property of the specified event.
  • the steps of the method may be repeated to generate multiple rules for one or more segments, in some examples for each segment, of the data.
  • multiple patterns may be identified and one, some or all of those patterns may be translated into rules.
  • Figures 2a to 2d are flow charts illustrating process steps in another example of method 200 for generating a rule for the grouping of network data into incidents.
  • the network may comprise any type of network comprising two or more communicating network nodes.
  • Such a network may be a telecommunications network such as a 3GPP network, an IoT network, a data center, a Local Area Network (LAN), a Wide Area Network (WAN) etc.
  • the method 200 illustrates one way in which the steps of the method 100 may be implemented and supplemented to provide the above discussed and additional functionality.
  • the method comprises, in step 210, obtaining time series data representing operation of the network, the time series data comprising notifications of events occurring within the network.
  • the notified events may comprise fault alarms, performance alarms, performance events and/or environment events.
  • a fault alarm may be generated by a network node or function in the event of a suspected fault such as a missed heartbeat message, a lost connection etc.
  • a performance alarm may be generated by a network node or function when a monitored performance parameter attains a threshold. Performance alarms may in some examples not be distinguished within alarm data.
  • a performance event may comprise a periodic or scheduled notification of a monitored performance parameter.
  • a scheduled performance event may not necessarily be periodic.
  • An environment event may comprise a notification of a condition in an environment in which the network operates, such as for example a temperature, precipitation or other sensor notification from an environment in which one or more network notes nodes is deployed.
  • the time series data may be historical data obtained from a network repository for such data such as a Network Operations Centre, Operations and Management node, etc.
  • the network repository may comprise a data storage location such as a data lake or data warehouse according to different installation or deployment scenarios.
  • the method 200 further comprises, in step 220, dividing the obtained time series data into segments, a segment comprising data representing operation of a part of the network.
  • the operation of the network may be represented via network performance and/or any other network event.
  • Figure 2b illustrates an example of how this division may be carried out.
  • the method may comprise obtaining metadata describing a physical network deployment. This step may be appropriate if clustering is to be performed on the basis of physical network node location, as discussed below.
  • the method comprises obtaining a context radius for use in clustering of network nodes.
  • the method comprises mapping network nodes to their physical locations.
  • the method comprises clustering network nodes in accordance with a property, which property may be selected from physical network node location, topology relation, and/or node context.
  • the node context may comprise for example an identifier such as a room identifier for an IoT sensor or a name or type of data transmitted by a network node.
  • the context radius may be obtained from a network operator or domain expert.
  • the context radius may in some examples be a geographical radius based on physical node location, but may alternatively comprise a functional radius, such as a coverage zone for a telecommunications network node, a sensitivity radius for an environment sensor etc.
  • the coverage zone of the telecommunications network node may correspond to the physical coverage zone or cell of a RAN node, or to a core network node coverage zone, encompassing multiple RAN cells from which traffic is directed through the core network node.
  • the telecommunications network node itself may therefore be physically located within the coverage zone or may be located outside the coverage zone, for example in the case of a core network node which may manage traffic, mobility etc. for user equipments in a geographic location which is remote from the physical location of the core network node, particularly in the case of cloud based core networks.
  • the method further comprises in step 225, for individual clusters of network nodes, referred to in the Figure as“node clusters”, identifying a level of network partitioning at which a percentage of network nodes within the cluster belong to the same part of the network, the percentage being above a threshold level.
  • the method then comprises, in step 226, selecting a level of network partitioning for the time series data on the basis of the levels identified for individual clusters of network nodes, and in step 227, grouping the obtained time series data such that notifications of events received from network nodes in the same part of the network, according to the selected level of network partitioning, belong to the same data segment.
  • the levels of network partitioning may be based upon a network management model, such that parts of the network may correspond to groups of network nodes which may be collectively managed. Examples of such groups may include managed environments such as rooms, floors, buildings etc. within an IoT deployment, nodes, sites or regions within a telecommunications network, districts or cities within a WAN etc. It will be appreciated that such partitioning generally corresponds to a geographical grouping of network nodes, and the levels of network partitioning may in some examples correspond to geographical divisions of the network. The partitioning of the network may be such that a single part of the network spans multiple logical network domains.
  • a partitioning of a telecommunications network may include elements of a Radio Access Network (RAN), transport network and core network within a single network part.
  • RAN Radio Access Network
  • Each of the included RAN, transport and core network nodes may service traffic originating within the region on which the network part is based.
  • the method 200 comprises performing subsequent steps for a segment of time series data.
  • the steps may be performed for one, some or all segments of data.
  • the method comprises normalising a structure of the time series data into time series data items, a time series data item comprising a property of a notified event. Normalising a structure of the time series data into time series data items may allow input data from different domains to be recast into a neutral structure such that disparate data structures or data sets in their original forms may be converted to the neutral structure referred to as items for subsequent processing. Steps that may be carried out in order to normalise a structure of time series data are illustrated in Figure 2c.
  • the normalising of a structure of time series data may, in a first step 231, comprise obtaining metadata describing features of notified events to be included in data items, a feature comprising at least one of a property of an event or a resource associated with an event.
  • obtaining metadata describing features for inclusion in data items may in some examples comprise generating the metadata by conducting component analysis on obtained time series data to identify event features for itemisation, and describing the identified event features in metadata.
  • the event features for itemisation may be identified in the component analysis as those features having an importance above a certain threshold measure, or those features appearing most often amongst different events.
  • Existing algorithms such as Principal Component Analysis (PCA) may be used to identify event features for itemisation.
  • PCA Principal Component Analysis
  • an event such as an alarm or a performance event may contain many features including properties and/or resources associated with the alarm or event.
  • a performance event may for example be scheduled periodically to report statistics including packet drop count, in packets, out packets etc.
  • Another example may be include temperature reading, sensor or actuator switched on time, fan speed, number of swings etc.
  • Not all of these features of a performance event may be significant from a fault analysis perspective. Including all features into data items may therefore impose additional computational load in the normalising and subsequent process steps for little or no advantage in terms of insight gained into network functioning. Identifying those features that will provide the greatest insight in terms of incident identification therefore enhances the computational efficiency of the method.
  • the obtaining of metadata may therefore comprise a step 23 lb of, for identified features represented as a value within a continuous range, clustering the values of the identified features in the obtained time series data.
  • Obtaining the metadata may further comprise assigning identifiers to the clusters in step 23 lc, generating a mapping to convert values within the continuous range to one of the cluster identifiers in step 23 lc and describing the mapping in metadata in step 23 le.
  • the process of generating metadata may be carried out for individual event types, such as for particular performance event types, environmental event types etc.
  • normalising the time series data may comprise obtaining a rule template specifying a data structure for data items in step 232, and for notified events in the time series data, generating a data item comprising at least a property of the event in accordance with the obtained metadata in step 233 and associating the generated data item with a time stamp associated with the event in step 234.
  • generating a data may comprise, for properties represented as a value within a continuous range, mapping the value of the property to a cluster identifier in accordance with the mapping described in the metadata in step 233 a, combining the property or mapped cluster identifier with a resource associated with the event in step 233b, and encoding the cluster identifier in a data structure specified in the obtained rule template in step 233c.
  • notified events in the time series data may comprise a plurality of features, some or all of which may be described in the obtained metadata.
  • a data item may be generated for each of the features described in the obtained metadata, and the generated data items may each be associated with a time stamp associated with the event.
  • multiple data items may be generated from a single event, should the event comprise multiple properties or resources specified in the metadata for inclusion in data items.
  • all of the generated data items are associated with the same time stamp corresponding to the event from which they were generated.
  • the method 200 further comprising, following normalisation of the time series data structure, grouping the normalised time series data items into transactions in step 240, wherein a transaction comprises a group of time series data items occurring within a time window.
  • grouping the time series data items comprises obtaining a time window in step 241 and grouping time series data items occurring within the same time window into a transaction in step 242.
  • the time window obtained in step 241 may be a sliding window or a tumbling window and may in some examples be specified by a network operator or domain expert.
  • the time window may be obtained from historical problem tracking records such as trouble tickets, as described in RFC 1297, among others.
  • obtaining a time window may comprise obtaining such historical problem tracking records.
  • Obtaining a time window may then comprise identifying time windows within which the events in the problem tracking records occurred in step 24 lb, and selecting as the obtained time window one of the identified time windows in step 24 lc.
  • the time window may be selected as the time window that would encompass a proportion of the obtained historical records that is above a threshold value, an average time window, a highest distribution time window, etc.
  • the method 200 comprises, for a segment of time series data, identifying a pattern of time series data items in the transactions using a machine learning process in step 250, a pattern comprising a set of data items that are correlated.
  • the nature of the correlation that may be present between the data items in a pattern may depend on the nature of the pattern identified.
  • Various different patterns may be identified using one or more pattern mining algorithms such as N-gram, skip-ngram, Apriori, ECLAT, FP-Growth etc.
  • Machine learning processes can require a large amount of computational power and time, and in some examples of the method 200, these requirements may be managed as set out in steps 251 and 252.
  • the method comprises monitoring at least one of resource requirements or time requirements for the machine learning process, and in step 252, the method comprises adapting at least one parameter of the machine learning process in accordance with the monitored requirements.
  • the parameter may be a threshold such as the Minimum support threshold for pattern identification, or the number N of patterns to be identified in the Top N frequent item set mining algorithm. Adapting of parameters may for example take place if thresholds for resource or time requirements are exceeded, to reduce the resources (memory or computational) or time required to complete the identification of one or more patterns.
  • the method 200 comprises translating the identified pattern into a rule in step 260, wherein the rule comprises a specification of events to be grouped into a network incident, a specified event being identified by a data item comprising a property of the specified event.
  • Translating the identified pattern into a rule may comprise listing the correlated data items of the pattern in a structure consistent with a rule template in step 261.
  • examples of the method 200 comprise predicting an amount of time to generate a new rule in step 270, and, if the predicted time exceeds an acceptability threshold as assessed at step 280, performing at least one of generating a rule for only a subset of segments and/or generating a rule for a subset of event generating entities in step 290.
  • the subset of event generating entities may share a contextual or logical link.
  • the context for the link may be geographical and/or functional.
  • Examples may include all entities in a room, all entities supplied with power by a given electrical power supply, all entities connected to the same ring main, all entities serving wireless devices in a given cell or group of cells etc.
  • the subset of segments and/or subset of event generating entities may have experienced network changes rendering previously generated rules obsolete. Previously generated rules for the remaining segments and/or event generating entities may be maintained.
  • Figure 3 is a flow chart illustrating process steps in a method 300 for processing network data.
  • the method 300 may be carried out during an online phase as part of an incident management framework.
  • the method 300 comprises obtaining online time series data representing operation of the network, the time series data comprising notifications of events occurring within the network.
  • the online time series data may in some examples be an online example of the historical data obtained as part of the methods 100 and/or 200.
  • the method 300 comprises obtaining a rule for the grouping of network data into incidents, the rule comprising a specification of events to be grouped into a network incident, a specified event being identified by a data item comprising a property of the specified event.
  • the obtained rule may be generated by a method 100 and/or 200 as described above.
  • the method 300 then comprises obtaining a time window in step 330, which time window may be the time window used for generating transactions during generation of the rule obtained at step 320.
  • the method 300 then comprises obtaining metadata describing features of notified events applicable to the obtained rule in step 340.
  • the metadata may be the same metadata as was used for normalising time series data during generation of the rule.
  • the method 300 then comprises normalising a structure of the obtained time series data into time series data items, a time series data item comprising a property of a notified event in step 350.
  • This may comprise generating time series data items corresponding to features specified in the metadata, substantially as described above with reference to method 200. Time series data items for features of the notified events that do not appear in the obtained metadata may not be generated.
  • the method 300 then comprises comparing the normalised data items to the specification of the rule (referred to after as the“rule specification”) and the obtained time window in step 360, and if, within the normalised data items, a set of data items exists that matches exactly to the data items in the rule specification and occurs within the obtained time window, as illustrated in step 365, then grouping the events corresponding to the data items of the set as a detected incident in step 370.
  • An exact match may require that every data item present in the rule specification also be present in the set. It will be appreciated that an event corresponding to a data item comprises the event form which the item was generated, that is the event having the property that is comprised within the data item.
  • the method 300 may comprise grouping the events corresponding to the data items of the set as a predicted incident.
  • a partial match may require that at least a threshold percentage of data items present in the rule specification also be present in the set. If a partial match is found then it may be predicted that the remaining events in the rule specification have not yet happened, meaning an incident may be about to take place, or in the process of taking place.
  • Figures 4 and 5 are block diagrams illustrating examples of apparatus 400, 500 which may carry out examples of the method 100 and/or 200.
  • Figure 4 illustrates a first example of apparatus 400, which may implement some or all of the steps of method 100 and/or 200, for example on receipt of suitable instructions from a computer program 406.
  • the apparatus 400 comprises a processor 402, a memory 404 and interfaces 408.
  • the memory 404 contains instructions executable by the processor 402 such that the apparatus 400 is operative to conduct some or all of the steps of the method 100 and/or 200.
  • the instructions stored on the memory 404 may in some examples comprise the computer program 406.
  • Figure 5 illustrates another example of apparatus 500, which may also implement some or all of the steps of method 100 and/or 200, for example on receipt of suitable instructions from a computer program.
  • the apparatus 500 comprises a plurality of functional modules, which may execute some or all of the steps of method 100 and/or 200 on receipt of suitable instructions for example from a computer program.
  • the functional modules of the apparatus 500 may be realised in any appropriate combination of hardware and/or software.
  • the modules may comprise one or more processors and may be integrated to any degree.
  • the apparatus 500 comprises an input module 502 for obtaining time series data representing operation of the network, the time series data comprising notifications of events occurring within the network.
  • the apparatus 500 also comprises a segmenter 504 for dividing the obtained time series data into segments, a segment comprising data representing operation of a part of the network, and an itemiser 506 for normalising a structure of the time series data in a segment into time series data items, a time series data item comprising a property of a notified event.
  • the apparatus 500 also comprises a transactioner 508 for grouping the normalised time series data items of a segment into transactions, wherein a transaction comprises a group of time series data items occurring within a time window.
  • the apparatus 500 also comprises a pattern mining engine 510 for identifying a pattern of time series data items in the transactions of a segment using a machine learning process, a pattern comprising a set of data items that are correlated, and a rule translator 512 for translating the identified pattern into a rule, wherein the rule comprises a specification of events to be grouped into a network incident, a specified event being identified by a data item comprising a property of the specified event.
  • the apparatus 500 also comprises interfaces 514.
  • Figure 6 presents an overall system architecture, illustrating how a typical alarm correlation solution may be extended with new components that enable automatic generation of alarm/event correlations in the form of rules according to examples of the present disclosure. Such automatically generated correlations are referred to in the following discussion as Machine Learning (ML) generated grouping rules.
  • the overall system architecture 600 of Figure 6 illustrates the data inputs 602, system components 604, intermediate artifacts 606 and output artifacts 608 that may be comprised within, generated by the system architecture 600 according to examples of the present disclosure.
  • a typical alarm grouping solution comprises an imperative rule coding system in which a database of rules is implemented using procedural (imperative style) language notation or through “condition: action” notation, in which the action typically follows procedural language based implementation.
  • a live stream of alarms is passed into an alarm grouper one by one to form groups of alarms. This essentially correlates the alarms with one another using domain specific knowledge encoded in the rules and specific property values in the alarms.
  • These groups of alarms, known as incidents are handled by the network/infrastructure operations team with the aim of resolving the underlying problem.
  • Examples of the present disclosure augment such known systems with ML based rule generation and interpretation of the generated rules.
  • RGF refers to steps through which the rules are generated automatically, according to examples of the methods 100 and/or 200.
  • RGF may be a functional unit or apparatus, and Figure 7 illustrates example functional units which may comprised within RGF 700, and their interrelations.
  • Functional units within RGF may include:
  • An itemizer 704 in which data is prepared for applying against ML algorithms.
  • the itemizer 704 abstracts the dependency between the structure of a generated rule and how the input data is adapted for application of pattern-mining algorithms.
  • RGE 706 A Rule Generation Engine (RGE) 706 in which ML rules are generated.
  • Existing pattern mining algorithms may be extended as part of RGE to solve rule-generation challenges.
  • a Rule refresher 708 in which insights may be learned about rule generation infrastructure and which may influence incremental learning and unlearning.
  • a Rule validator (not shown) may also be included, and may be responsible for obtained insight or feedback from users of the ML rules on the quality of the rules generated.
  • the insights obtained can be incorporated while filtering the rules or could be used for further evaluation of the system as a whole.
  • each data layer could have its own performance and functional characteristics and hence the data layer could be chosen by the user based on their requirements.
  • the interfaces between the various components are in the form of intermediate artifacts such as segmented alarms, items, RGE statistics etc.
  • FIG 8 is a sequence flow diagram illustrating interactions between functional units according to examples of the present disclosure.
  • the RGF initiates a batch processing to query for a set of alarms/events/time-series data for a predefined historical period.
  • the Event History module which is a repository of historical data, responds back with history data.
  • the RGF sends the history of alarms/events/time-series data to the Segmenter.
  • the Segmenter component responds with segmented datasets of the input data.
  • the segmented dataset typically is expected to follow the same structure as the input history data, however divided as described in greater detail below.
  • the RGF sends the segmented data (from step 802) to the Itemizer.
  • the Itemizer adapts the input data such that their respective structures are normalized for applying against ML algorithms.
  • the Itemizer returns Itemized versions of the segmented data.
  • the itemization process may be dependent rule- structure and rule- template of rules to be generated and on properties that are of interest to a given rule. Itemization also involves handling multi-value scenarios as in performance events or time- series data as applicable enabling pattern mining algorithms to generate patterns.
  • the RGF sends the Itemized data (which retains time-series notation) to the RGE component. This component responds with ML generated rules that adheres to certain metadata (rule-structure/rule-template/selected input data properties).
  • the RGE also generates statistics to adapt behavior automatically.
  • the RGF aggregates all the ML rules into a rule-repository for usage by an ML generated Rules Interpreter (MRI) component described in further detail below.
  • MRI ML generated Rules Interpreter
  • the segmenter takes in the historical datasets (alarms, events, time-series, etc.) of the network and splits them into possible layers of segmentation. This is done to eliminate issues (such as false-positive rules) in which the alarms from unrelated network nodes from different segments in the network are correlated in a way that does not have any logical relationship from a given domain perspective. While using unsegmented data, generated rules will look correct according to the data, however not correct with respect the domain (telecom or IoT) of the data. The Segmenter differentiates between alarms occurring from various nodes across the network at the same time.
  • Segmentation here could be done in various layers of partition, for example at a region layer or site-layer in the case of telecommunications networks. This layer of segmentation could vary depending on the type of network. In another example for an IoT based infrastructure, the layers of abstraction could be different cities, different states, countries or even different level of floors in a building. It is desirable to group the network nodes such that the generated rules are logically correct and applicable with respect to the deployment.
  • FIG. 9 is a block diagram illustrating functional units within a Segmenter 900.
  • the Segmenter 900 considers various possible levels of segmentation and estimates the best possible segmentation, given requirement of a particular deployment.
  • Input to the Segmenter 900 are alarms/events data and site-metadata information, which may be available from a Network Operations Centre (NOC) system.
  • NOC Network Operations Centre
  • Also input to the Segmenter is contextual radius information which may be input by a user or administrator.
  • the Segmenter 900 outputs segmented time series data.
  • Functional units within the Segmenter 900 include a Distance estimator 902, an ML Clusterer 904 and a Cluster-layer mapper 906.
  • the Segmenter identifies the appropriate abstraction layer for segmentation in terms of architectural logic to facilitate correlation of event sequences. This uses an underlying network characteristic as epsilon radius to identify the best possible layer for segmentation which could yield the most accurate logical combination of events.
  • Step 10 illustartes sequence flow within the Segmenter 900.
  • step 1001 input alarms/events stream and site-metadata information from a NOC system are fed into a distance estimator together with site metadata information.
  • the distance estimator processes and maps the network nodes to their geographical location. This mapping of geographical node location is passed to the Clusterer in step 1002.
  • step 1003 the Clusterer uses the Contextual radius (which may be domain specific) to cluster the network nodes.
  • the Contextual radius which may be domain specific
  • the contextual radius There are many ways to identify the contextual radius and perform clustering.
  • One such example is using geographical ranges as the contextual radius.
  • the contextual radius in the case of telecommunication networks could be the transmission coverage range and in case of IOT could be the range of the underlying sensor network.
  • step 1004 the clustered groups of network nodes are then initiated into the Cluster-Layer mapper.
  • This component takes each of the clusters and estimates a score by comparing it with the different abstraction layers. In the following example, it is assumed that there are five network nodes in a cluster having the network characteristics illustrated below. The minimum similarity score level required is assumed to be 80%
  • Abstraction 2 is therefore chosen for this example cluster. All clusters are scored similarly. After cluster level scoring, an abstraction layer for the entire dataset is selected based on an abstraction layer that scored highly among a majority of the clusters.
  • step 1005 the chosen layer is used for segmenting the entire network data into segments for forwarding to the Itemizer.
  • telecommunications network data comprises logical layers such as region, site, node etc.
  • a Segmenter might choose site abstraction layer and hence, split the entire network data into site-specific data segments.
  • the Itemizer takes the segmented data from the Segmenter as input and automatically generates output data which is in a normalized/neutralized structure called Items. These items represent the original time-series segmented data which can reveal patterns of repetitions or co-occurrence. Groups of items that have a correlation or co occurrence pattern are identified by pattern mining algorithms as ML rules in future steps.
  • the Itemizer enables ML rules to be generated not just on the basis of a single data set such as alarm data form a single subsystem, but based on a range of data sets from different heterogeneous systems.
  • the rules may be based on just on alarm data but also on performance or environment data, which help in generating rules that not only detect incidents that have occurred but may predict future events likely to happen, for example recognizing the conditions that have in the past preceded a particular type of incident.
  • An ML generated rule that has only alarm related items identified is based entirely on faults that have already occurred in the infrastructure. Such a rule is only useful to the extent of grouping to allow detection of composite condition and enable further root- causing and future resolution steps.
  • an ML generated rule may include a set of Items that displays correlation/co-occurrence etc. and may be used to predict faults.
  • a rule can indicate that the associated fault may occur with a certain probability.
  • a challenge in including data for fault prediction is that input data to the Segmenter will be of varying formats and structures in accordance with the different data-sources.
  • the segmented data retains its original structure after from segmenting.
  • Alarm dataset An alarm is indicative of a single fault, but in a typical infrastructure a number of such alarms can be grouped together to form an incident (detection) .
  • Performance alarm dataset A performance alarm is a threshold causing condition (of specific counter or measurement or performance related parameter violations) reported through manual or domain expert specified rules. This may be considered as equivalent to an alarm as above and indicative of a warning of a minor or major condition. Many performance events (defined below) from an infrastructure may be used to monitor and report a performance alarm.
  • Performance event dataset A performance event or environment reporting represent a type of information that is typically reported periodically or through scheduled notification mechanisms.
  • a node in management infrastructure or an application collects a number of properties that are specific to a certain domain and reports them using different reporting protocol methods such as SNMP or NetConf or LWM2M etc. or through any application specific monitoring protocols, interfaces or messages.
  • FIG. 11 is a block diagram illustrating an example Itemizer component 1100.
  • Metadata input to the Itemizer 1100 may identify fields such as unique node id, alarm notification type, performance event type, performance indicator property or weather data when dealing with data external to the managed infrastructure.
  • This component makes use of the candidate features in metadata from the input dataset and processes the data such that alarm/event data is encoded as a data item. These data items are then passed on to the RGE component.
  • rule metadata & rule template are two other inputs to the Itemizer 1100 that assist this component in producing normalized Item structure data.
  • Rule metadata identifies the properties from the segmented input that need to be extracted and converted and into an Item.
  • Rule template identifies the structure of the output ML generated rule-segment for the selected properties in the metadata.
  • the Itemizer may self-decide which fields should to be considered for creating an item. By generating each item as an encoded representation based on metadata, the Itemizer enables an explicit understanding of actionable insight, so facilitating reverse interpretation of generated rules at MRI once ML rules are generated.
  • Figure 12 illustrates sequence diagram for Itemizer behavior when handling alarm data. The steps illustrated in Figure 12 are carried out for each alarm/event in segmented data.
  • the Itemizer requests metadata for the dataset, which metadata is received in step 1202.
  • the Itemizer requests a rule template, which rule template is received in step 1204.
  • the Itemizer sends a request to its encoding function to encode the alarm/event together with the obtained metadata and template.
  • the Itemizer receives the encoded alarm/event in the form of items.
  • Example alarm features from telecommunications network data include network NODEID, NODETPYE of the node generating the alarm, the specific problem reported (X733SPECIFICPROB) in the alarm and many more possibilities.
  • the specific problem reported in the alarm may be reported in accordance with an appropriate telecommunications standard such as the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Recommendation X.733.
  • ITU-T International Telecommunication Union Telecommunication Standardization Sector
  • the PSE converts individual performance event into‘n’ number of items (if there were ‘n’ properties in that event) each encoded items having the timestamp of the original performance event. Items on the output side are in a rationalized structure that allows identification of patterns across alarm based items and performance event based items.
  • feature metadata for a performance event type may indicate either properties or attributes of interest or a domain specified list or all properties.
  • the rule template provides the encoding rules specifying how the individual property identified in the feature metadata is to be encoded.
  • Figure 14 illustrates process flow in the PSE. Referring to Figure 14, for each performance event, the PSE requests and receives metadata in steps 1401 and 1402. The PSE then requests and receives a template structure in steps 1403 and 1404. The PSE then performs subsequent steps for each applicable property form the metadata (this may be only properties listed in the metadata or the metadata may specify excluded properties or all properties). In step 1405, the PSE sends a request to its encoding function to encode the event together with the event type, template and applicable property. In step 1406 the PSE receives the itemized entity for that property, and in step 1407, the PSE accumulates the obtained items.
  • An Automatic-event encoder illustrated in Figure 15, is a method used by the overall system (or the PSE) to automatically determine the important information from performance events for encoding as items.
  • the properties that act as discriminating information are identified automatically, making itemization independent of domain experts and a fully data driven step
  • the AEE may additionally handle properties in a performance event (such as current temperature or packet drops etc.) which may be values in a continuous range. Continuous ranges for features may explode the rule-space, and the AEE may provide one way of automatically managing this complexity, which may impact the usefulness of the rules generation in certain domains.
  • a temperature value for example, instead as being provided as a raw value may be categorized as very hot, hot, neutral, cold, very cold etc. Such clustering of values into categories may simplify later pattern identification.
  • the AEE requires additional computation for clustering of the input value ranges, but leads to a robust solution because this method automatically abstracts the value ranges as appropriate based on data and, hence retains a method that is problem and domain agnostic. Clustered values also reduce the rule space and increase readability.
  • the AEE 1500 takes in historical time-series performance data as input. It finds key components in the performance events/measurements using component analysis methods such as Principal Component Analysis (PC A) etc. For each of the important properties (referred to as variants), value ranges are automatically clustered (such as low, medium and high etc.). These clusters enable mapping of values within a range to a cluster identifier, so converting a numerical values into a categorical values.
  • PC A Principal Component Analysis
  • the AEE generates Variant mapping rules for each cluster and these rules are summarized into input metadata for the PSE for transformations.
  • the AEE thus identifies important information from input data that should form part of the rule-segments in the ML generated rules.
  • Figure 16 illustartes process flow for the AEE.
  • the PSE makes use of user specified inputs.
  • the AEE may in some examples generate these inputs and include them in metadata.
  • the AEE also handles discretization, so enhancing the usefulness of generated rules.
  • a first step 1601 the AEE requests historical event data, which data is received at step 1602. The following steps are then performed for all unique performance event types.
  • the AEE sends a request to generate metadata for the event type to its metadata generating function.
  • the metadata generating function requests component analysis to find variants, for example using PCA, in step 1604. These variants are returned in step 1605.
  • step 1606 the metadata generating function requests its clustering algorithm to cluster selected variables (for example those variables which are represented as values in a continuous range). Theses clusters are returned in step 1607.
  • step 1608 the metadata generating function converts clusters to conversion rules and in step 1609, the metadata generating function generates conversion rules for the event type.
  • step 1610 the metadata generating function returns the generated metadata, which is then updated by the AEE in step 1611.
  • FIG. 17 illustrates example functional units within an RGE 1700.
  • the RGE 1700 comprises a Transactionizer 1701, a Pattern Mining Engine (PME) 1702 and a Rule Translator 1703.
  • PME Pattern Mining Engine
  • FIG 18 is a sequence diagram illustrating the interaction between the functional components of the RGE 1700.
  • the RGE requests and receives data items form the Itemizer.
  • the received data items are then fed to the Transactionizer 1701 of the RGE 1700 and the Transactionizer returns transactions based on a sliding or tumbling window in step 1802.
  • the transactions, together with tuning properties are sent to the Machine Learning algorithms along with a request to identify patterns.
  • the ML algorithms instruct the Auto tuner to start monitoring and send configuration information for the tuning properties (received in step 1803) in step 1804.
  • the ML algorithms then start pattern mining in step 1805.
  • step 1806 the Auto tuner monitors the resource consumption of the ML algorithms and adapts parameters of the algorithms as appropriate in accordance with the configuration information received (time budget, minimum support parameter, maximum number of rules parameter etc.).
  • the ML algorithms then return the identified patterns in step 1807.
  • step 1808 the ML algorithms instruct the Auto tuner to cease monitoring.
  • step 1809 the identified patterns are sent to the Rule-Translator for translation into rules, and in step 1810, the Rule-Translator returns the ML generated rules that are the output of the RGE.
  • the RuleTranslator makes use of rule-template settings at system level and converts the generated patterns to a suitable format for offline consumption by the MRI. This component bridges the rule format expectation at the MRI component, so rendering the identified patterns as actionable insights that can be used by an application such as the MRI.
  • Data items from the Itemizer are input to the Transactionizer 1701.
  • the Itemizer function normalizes the time series data of alarms/events/etc. into time series items, and these items are then input to the Transactionizer where they are grouped according to a certain time-horizon (for example within a certain time-window period) to form groups of items called transactions, which are then output form the Transactionizer. For example, if alarml occurred along with alarm2 within 5 minutes of each other, if these two alarms are part of a single transaction, (the time window for the transaction being 5 minutes) and there are many such repeated occurrences of alarml and alarm2 in other monitored time- periods, then they would repeat in other transactions.
  • Pattern mining algorithms may identify these transactions to pull out groups of alarms that are co-occurring repeatedly across transactions (in one simple form) and identify such significantly repeating combinations as patterns of behaviors displayed by the data.
  • the Transactionizer requires the time-window for transactions to be specified as input, as illustrated in Figure 19.
  • time-series items are converted into transactions using sliding window or tumbling window transactionzation procedures.
  • a challenge of transactionizer functionality is to establish the appropriate time window.
  • the time window can be either domain-expert specified or can be automatically learned from a history of problem tracking records such as trouble tickets and their constituent alarms, or from the work-orders generated.
  • the ideal time-window for identifying co-occurrence in transactions is identified from these data sources and the stream is split into transactions on the basis of the time window.
  • An automatic method to infer suitable time-window from referred historical information is depicted in Figure 20.
  • a time window of an incident in the trouble ticket is established in step 2002, the time window extending from the earliest alarm/event to latest alarm/event in that ticket.
  • a distribution is then created of the time windows in step 2003 and a highest distribution time window is selected in step 2204, the highest distribution time window being that time window which would capture most of the incidents occurring in the historical trouble tickets.
  • Transactions may be created on the basis of either sliding- window or tumbling-window formations to enable the pattern recognition algorithm to form groups based on various significant factors including co-occurrence, co-relation etc. Generated transactions are then input to the PME.
  • Pattern Mining Engine PME
  • An example PME component 2100 is illustrated in Figure 21, and comprises customized ML Algorithms 2101 to identify the patterns and an Auto Tuner 2102 which adds a capability to monitor and tune or adapt the behavior of the algorithms.
  • the Pattern Mining Engine (PME) component 2100 takes the transactions 2103 as input along with optional operator specified mining algorithm and other configurable inputs such as min- support 2104, max-n-rules 2105, feature weights 2106 and time-budget 2107 etc. as discussed in further detail below.
  • the PME outputs patterns 2108 identified in the transactions. Patterns 2108 are key insights into the data which are then translated in the ML generated rules.
  • the ML algorithms 2101 may include multiple different ML algorithms 2101 a to 2l0ld.
  • Traditional or typical ML algorithms for pattern identification do not display a deterministic behavior, owing to the nature of data, memory needs, time constraints and computational needs that may vary for each selection made in the configuring or running of the algorithms.
  • Such traditional algorithms are extended in the PME to enable external control which can handle resource constraints (memory, computational and time) imposed in different problem settings.
  • the external control is provided by the Auto Tuner 2102 as discussed in further detail below.
  • Each algorithm may include its own set of properties to distinguish a type of patterns to identify.
  • One example property is min-support 2104, which specifies that groups or alarms or events related items repeating in a certain proportion of transactions that attains the minimum support level should be reported as output patterns.
  • min-support 2104 specifies that groups or alarms or events related items repeating in a certain proportion of transactions that attains the minimum support level should be reported as output patterns.
  • ‘Top N rules only’ specifies a maximum number of patterns 2105 to look for.
  • Other example variants of algorithms extended may include FPGrowth, Top-N, ECLAT etc.
  • the resulting output from these algorithms are patterns 2108.
  • the output patterns are sent to the Rule Translator to create ML generated rules.
  • the Auto-tuner handles the decision making to automatically choose the appropriate parameters for the algorithms via the Parameter Shifter 2l02a.
  • the Auto Tuner 2102 monitors execution of the pattern identification process, for example using Timer 2102b as well as other functionality for monitoring processing and/or memory resource usage, and upon threshold violations it adapts the behavior of the ML algorithms accordingly.
  • the Auto Tuner 2102 allows for adaptive behavior by changing parameters to enable reasonable output generation, so enabling a best effort rule generation instead of letting the system fail due to resource limitations. Dynamically shifting the min- support (for example increasing min- support to place a higher threshold for pattern identification) when an ML algorithm is operating at a level of resource consumption that violates a given limit places working constraints on the resource consumption of the ML algorithm, so rendering a practical and viable rule- generation system.
  • New min-support old min-support + (old min-support /100 * X) ⁇ i.e. increase by X% ⁇ This essentially reduces the search space due to higher co-occurrence expectations, adapting the behavior of the system.
  • X may for example be 10 %.
  • Top-N Frequent Item Set mining algorithm looks for only the top-n patterns. However, when the‘N’ is very large, resource limitations may occur and the Auto Tuner 2102 may shift the value of N to a lesser value:
  • New N Old N - (Old N/100 * X) ⁇ i.e. reduce by X% ⁇
  • X may for example be 10 %. It will be appreciated that different rates of increase of min-support and reduction of N may be envisaged.
  • the Rule Translator component processes the output from the pattern mining algorithms, post-processing the generated patterns into generated rules using a rule- template supplied by a user or administrator.
  • the Rule Translator thus recasts the patterns into a format that is readable and usable by an interpretation application that is to use the rules in the processing of network data.
  • An illustration of the conversion from generated patterns to customizable rule using a rule-template is given below in the section headed “Illustrations of ML generated rules, metadata and rule template” . It will be appreciated that the Rule Translator may be used in circumstances in which it is desired to expose the rules to any other components through API’s, according to which the rules could be converted to standard formats such as xml, json etc. using the Rule Translator.
  • the Rule refresher is an additional functional component which may operate alongside the segmenter, itemizer, RGE etc.
  • the Rule refresher aids in unlearning and re learning of new rules derived from new data.
  • Full ML rule generation may take a considerable amount of time and computational resource, depending on the size of the network and the computational capabilities of the system.
  • previously generated rules may be used for processing of network data.
  • the Auto tuner in the PME may reduce this time and resource usage by adapting the behavior of the algorithms. Further optimization may be achieved by selectively generating rules and such optimization is provided by the actions of the Rule Refresher. In situations involving time-critical applications or extremely fluctuating networks, the Rule Refresher effectively optimizes the Rue Generation process itself.
  • Rule Refresher 2200 is illustrated in Figure 22 and comprises a statistics store 2201, a predictor 2202, a priority filter 2203 and a refresh trigger 2204.
  • the Rule-refresher 2200 predicts a time required for rule-generation in the predictor, which prediction may be based upon network statistics such as alarm fluctuations, sensitivity, size of the layer (in-terms of faults/events/nodes) obtained from the statistics store. If the predicted time exceeds an acceptable level, then the rule-refresher causes rules for only a part of the network to be updated, based on priority filtering of parameters specified by a user or obtained by any other means from the statistics store 2201.
  • the statistics store 2201 collects and stores various network statistics such as alarm fluctuations (massive changes in the alarm rate without any changes in the underlying topology and which could for example be caused by fluctuations in the environment such as temperature), sensitivity (rate of alarms with respect to changes in the topology such as addition of a node to a site), size of the layer (in terms of faults/nodes).
  • alarm fluctuations mass changes in the alarm rate without any changes in the underlying topology and which could for example be caused by fluctuations in the environment such as temperature
  • sensitivity rate of alarms with respect to changes in the topology such as addition of a node to a site
  • size of the layer in terms of faults/nodes
  • the predictor 2202 takes input from historical RGE statistics concerning about rule-generation. ML time-series based prediction is then performed and an estimated time to carry out a next rule-generation is derived for the entire process of rule -generation (starting from segmentation to rule-generation).
  • the priority filter 2203 takes input from the statistics store on the various network statistics and assigns a priority to each layer. This assignment depends on a characteristic chosen by the user in the priority filterer. For example, a user may set the priority filter to assign priority to layers in terms size of the layer (a network characteristic taken from the statistics engine) and assign priority accordingly.
  • the Refresh trigger 2204 triggers the next rule-refresh based on the predicted time obtained from the predictor. Thus, if the predicted time is above an acceptable threshold, then a rule refresh is triggered at the next rule generation time, as opposed to a full rule regeneration from segmentation to rule translation.
  • the Refresh trigger also decides which rules/layers are to be refreshed based on information from the priority filter. In a scheduled rule-generation scenario (for example where rule-generation is planned to be triggered every day), the refresh trigger is executed first to understand if an entire rule- generation is acceptable in terms of time taken, or if a rule refresh would be preferable.
  • This top-level component refers to the steps through which a new incoming stream of online phase alarms/events/time-series data are processed against the RGF/RGE generated rules, referred to as ML generated rules.
  • the MRI generates actionable groupings of alarms/events/etc. that represent an Incident (as these groupings are assumed to share a common set of root-causes or correlation patterns or co-occurrence patterns were significant).
  • An example MRI 2300 is illustrated in Figure 23 and sits as part of an alarm grouper which is enhanced to interpret the ML generated rules while it may also continue to work with imperative style rules.
  • the MRI 2300 may comprise a processor and a memory and may perform some or all of the steps of the method 300 described above for processing network data, for example on receipt of suitable instructions from a computer program.
  • the MRI component 2300 performs the following steps. The MRI first parses the input alarms/events and extracts properties with respect to the ML generated rules that are applicable. This step makes use of the metadata“feature metadata” that was used by the RGF’s Itemizer and RGF’s Rule Translator sub -components.
  • the metadata identifies the features of the alarms and events that are relevant to the rules that the MRI will be applying.
  • the MRI then matches these alarm items and/or performance items against the rule properties. Where there is a complete match to a rule within the time -window (as used in the transactionzer), those groups of alarms and events are short-listed as detected conditions. Where there is a partial match to a rule within the time-window (as used in the transactionzer), those groups of alarms and events are short-listed as predicted conditions.
  • Each group of alarms and events, where each group is related to single rule, is converted to an incident (detected or predicted).
  • Partially matching rules may be expected to develop over time to full matches, when the infrastructure repeats the behavior. Rule segments that are partially matched may therefore include faults which are about to happen within the rule time -window. In this case the MRI may project the expected time to reach a fault as indicated in the ML generated rule specific window assumptions.
  • a rule template follows a descriptive format to allow for the generation of ML rules that may be interpreted by an MRI.
  • feature metadata may identify the following fields of interest:
  • NODEID X733 SPECIFICPROB
  • NODETYPE X733 SPECIFICPROB
  • Metadata influences the itemization phase to encode each alarm/event.
  • the Rule- template then identifies the structure of the generated rule. For example:
  • Each item may encode multiple attributes and each of these attribute value pairs may be encoded using an attribute separator specified in the rule template.
  • the attribute separator is a
  • Items of respective alarms may be separated by an item separator specified in the rule template.
  • A may be used in one simple example
  • Alarml is itemized as Nl#SPl and similarly other alarms are itemized respectively
  • the rule-template may include a data source type indicator to assist interpretation at the MRI.
  • An example data source type indicator could be configured such that“A” is for alarm &“P” is for performance event.
  • Measurementl is the property from performance event dataset, Nl (nodeid), property measurementl with value being 10.
  • An example rule structure that composes Alarm & Performance event with AEE is as follows:
  • Measurementl is the property from performance event dataset, Nl (nodeid), property measurementl with value being Low indicating the AEE has injected conversion rules to convert 10 to Low (Low being mapped for example to values in range 5 to 25) before forming the Item as part of the itemization.
  • the network is generally divided into logical layers of region, site and nodes as illustrated in Figure 25.
  • a fault management system in a telecom network that incorporates the above described implementation of methods and apparatus according to the present disclosure would perform the following steps (illustrated in Figure 26):
  • the historical input data is sent to the Segmenter of the RGF in step 2601 where it is segmented.
  • the data is segmented into either regions or sites depending on the level of abstraction required.
  • the example illustrated in Figure 25 assumes segmentation at site level.
  • the output of the Segmenter is alarm and performance event data for each site.
  • the output from the Segmenter is then passed to the Itemizer in step 2602 which determines the definition of items for transactions.
  • the data is itemized into NODEID$PROBLEMSTRING or NODE_TYPE$PROBLEMSTRING, since these are the lower layers of abstraction available after segmentation. Itemization of alarms is completed in this phase.
  • the output is sent to the Transactionizer in step 2603 which decides the time-window of the transactions.
  • the time-window is derived by learning from historical trouble tickets which contain a manually correlated alarms list. It is assumed that the ideal time-window is found to be 5mins.
  • the data is then split into 5min sliding window transactions. In the present example a sliding window is used to avoid any loss of information and as a way to reinforce the most repeating group of alarms as rules.
  • the RGE After the transactionizing, the RGE finally provides the transactions to the Pattern- Miner in step 2604, and the Pattern-Miner may use any mining algorithm or the extended algorithm for the results.
  • the rules are generated, they are stored in the database in step 2605, from where they are fetched by the alarm-grouper for mapping.
  • the generated rules are matched against a new stream of alarms and matched groups of alarms are identified as a candidate incident.
  • a fault management system in an IoT network such as that illustrated in Figure 27, which system incorporates the above described implementation of methods and apparatus according to the present disclosure would perform the following steps:
  • the alarms are raised and sent to the fault management system from where they are stored in the database.
  • Alarms that have occurred are passed through the segmenter, which segments the faults according to the rooms.
  • the segmented data is then passed through the itemizer.
  • the item is defined as the SENS ORID $ AL ARMT YPE or SEN S ORTYPES ALARMT YPE depending on the layer of abstraction needed by the user.
  • ALARMT YPE will depend on the SENSOR that is generating the notification.
  • alarm data is then passed through the transactionizer to split the data into time-windows. Once the transactions are identified, the data is passed through PME algorithms to identify any possible patterns in the data.
  • the live alarm stream is passed through alarm-grouper.
  • the alarm-grouper identifies the rules for rooml , where the alarm was raised, and performs a mapping operation. The incidents are generated after matching and reported.
  • aspects of the present disclosure thus provide an automated Machine Learning based rule generation framework which takes historical alarms/events/other time series data generates rules automatically.
  • the generated rules may replace manually coded or scripted rules.
  • aspects of the present disclosure also provide an application that makes use of the generated rules to produce groupings known as incidents, which may be detected or predicted.
  • An advantage afforded by the methods of the present disclosure is that they are data- driven and hence applicable to multi-domain, multi- vendor situations. Examples of the present disclosure may also be adaptable and suitable for optimisation to take account of changes in a managed network, the network data or the patterns that occur in the data and evolve over time. Another advantage afforded by example methods of the present disclosure is the ability to tolerate out of order event or alarm reporting within a specified time window.
  • Examples of the present disclosure automatically generate machine interpretable rules for incident detection and prediction.
  • Example methods of the present disclosure are sensitive to resource constraints and adaptable to abandon rules that are no longer applicable and to incrementally update a rule repository by selectively refreshing rules.
  • Examples of the present disclosure can handle multiple disparate data such as alarms, performance events and other time-series data-sources like weather which leads to better detection & prediction.
  • Examples of the present disclosure offer the ability to consider performance events and faults together in a correlated manner, so enabling incident prediction. The onset of performance events leading to a fault alarm in a single rule may assist in prediction of a fault before it has occurred.
  • Examples of the present disclosure may include improved network fault/performance management operations productivity and improved response time for network issue resolutions.
  • Examples of the present disclosure enable quicker identification of root-causes of issue owing to all contextual information (including both alarm and performance data) being correlated as a single incident in an automatic manner.
  • the methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein.
  • a computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé (100) de génération d'une règle pour regrouper des données de réseau en incidents. Le procédé consiste à : obtenir des données de série chronologique représentant le fonctionnement du réseau, les données de série chronologique comprenant des notifications d'événements se produisant dans le réseau (110), et diviser les données de série chronologique obtenues en segments, un segment comprenant des données représentant le fonctionnement d'une partie du réseau (120) ; pour un segment de données de série chronologique, normaliser une structure des données de série chronologique en éléments de données de série chronologique, un élément de données de série chronologique comprenant une propriété d'un événement notifié (130), et regrouper les éléments de données de série chronologique normalisés en transactions, une transaction comprenant un groupe d'éléments de données de série chronologique se produisant dans une fenêtre temporelle (140). Le procédé comprend en outre, pour un segment de données de série chronologique, les étapes consistant à : identifier un motif d'éléments de données de série chronologique dans les transactions à l'aide d'un processus d'apprentissage automatique, un motif comprenant un ensemble d'éléments de données qui sont corrélés (150) ; et traduire le motif identifié afin d'obtenir une règle, la règle comprenant une spécification d'événements devant être regroupés en un incident de réseau, un événement spécifié étant identifié par un élément de données comprenant une propriété de l'événement spécifié (160).
PCT/IN2018/050550 2018-08-28 2018-08-28 Génération de règles pour données de réseau WO2020044352A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/IN2018/050550 WO2020044352A1 (fr) 2018-08-28 2018-08-28 Génération de règles pour données de réseau
EP18932045.0A EP3844921A1 (fr) 2018-08-28 2018-08-28 Génération de règles pour données de réseau

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IN2018/050550 WO2020044352A1 (fr) 2018-08-28 2018-08-28 Génération de règles pour données de réseau

Publications (1)

Publication Number Publication Date
WO2020044352A1 true WO2020044352A1 (fr) 2020-03-05

Family

ID=69643625

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IN2018/050550 WO2020044352A1 (fr) 2018-08-28 2018-08-28 Génération de règles pour données de réseau

Country Status (2)

Country Link
EP (1) EP3844921A1 (fr)
WO (1) WO2020044352A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111629034A (zh) * 2020-05-06 2020-09-04 深圳力维智联技术有限公司 物联网终端的远程维护方法与装置
US11496353B2 (en) 2019-05-30 2022-11-08 Samsung Electronics Co., Ltd. Root cause analysis and automation using machine learning

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150295780A1 (en) * 2014-04-15 2015-10-15 Splunk Inc. Grouping and managing event streams generated from captured network data
WO2017168524A1 (fr) * 2016-03-28 2017-10-05 株式会社日立製作所 Dispositif de serveur d'analyse, système d'analyse de données et procédé d'analyse de données
US20180081972A1 (en) * 2016-09-19 2018-03-22 Sap Se Filtering and processing data related to internet of things

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150295780A1 (en) * 2014-04-15 2015-10-15 Splunk Inc. Grouping and managing event streams generated from captured network data
WO2017168524A1 (fr) * 2016-03-28 2017-10-05 株式会社日立製作所 Dispositif de serveur d'analyse, système d'analyse de données et procédé d'analyse de données
US20180081972A1 (en) * 2016-09-19 2018-03-22 Sap Se Filtering and processing data related to internet of things

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11496353B2 (en) 2019-05-30 2022-11-08 Samsung Electronics Co., Ltd. Root cause analysis and automation using machine learning
CN111629034A (zh) * 2020-05-06 2020-09-04 深圳力维智联技术有限公司 物联网终端的远程维护方法与装置
CN111629034B (zh) * 2020-05-06 2023-07-25 深圳力维智联技术有限公司 物联网终端的远程维护方法与装置

Also Published As

Publication number Publication date
EP3844921A1 (fr) 2021-07-07

Similar Documents

Publication Publication Date Title
EP2997756B1 (fr) Procédé et dispositif de réseau pour détection d'anomalie de cell
US11489732B2 (en) Classification and relationship correlation learning engine for the automated management of complex and distributed networks
US11348023B2 (en) Identifying locations and causes of network faults
EP2487860B1 (fr) Procédé et système pour améliorer la détection de menaces de sécurité dans des réseaux de communication
US7275017B2 (en) Method and apparatus for generating diagnoses of network problems
US20220321436A1 (en) Method and apparatus for managing prediction of network anomalies
CN112769605B (zh) 一种异构多云的运维管理方法及混合云平台
US20210359899A1 (en) Managing Event Data in a Network
García et al. Automatic alarm prioritization by data mining for fault management in cellular networks
Solmaz et al. ALACA: A platform for dynamic alarm collection and alert notification in network management systems
CN115280741A (zh) 混合能量管理中的自主监测和恢复的系统和方法
EP3844921A1 (fr) Génération de règles pour données de réseau
Natalino et al. Flexible and scalable ML-based diagnosis module for optical networks: a security use case
Abed et al. Efficient failure prediction in autonomic networks based on trend and frequency analysis of anomalous patterns
US11005716B2 (en) Automatic customer bandwidth utilization analysis for promoting dynamic capacity
Kassan et al. Robustness analysis of hybrid machine learning model for anomaly forecasting in radio access networks
Kawahara et al. Application of AI to network operation
Li et al. A sensor-based approach to symptom recognition for autonomic systems
US20230076662A1 (en) Automatic suppression of non-actionable alarms with machine learning
Caravela et al. A closed-loop automatic data-mining approach for preventive network monitoring
EP4149075A1 (fr) Suppression automatique d'alarmes non actionnables avec apprentissage automatique
US20240113932A1 (en) Telecommunication network alarm management
US20230315954A1 (en) Method and device for dynamic failure mode effect analysis and recovery process recommendation for cloud computing applications
Ali‐Tolppa et al. Cognitive Autonomy for Network Self‐Healing
Kakadia An Exploration of Optimization Models for User Network Experience and Operational Efficiency Improvement Via Automation and Machine Learning

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18932045

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018932045

Country of ref document: EP

Effective date: 20210329