System anomaly management

Abstract

According to an example aspect of the present invention, there is provided an apparatus configured to compile plural time series of event records based on plural technical characteristics of the event records, the event records originating in a system, select, from among the plural time series, a set of time series, wherein each time series among the set of time series comprises at least one event record with a value determined by the apparatus to be anomalous or flagged as anomalous, compile an initial technical characteristic list by including in the initial technical characteristic list each defining characteristic of the time series in the set of time series, and obtain a second technical characteristic list by removing from the initial technical characteristic list those technical characteristics which are defining characteristics of time series which satisfy a predetermined condition.

Description

SYSTEM ANOMALY MANAGEMENTFIELD

[0001] The present disclosure relates to management of error information in large systems, such as communication networks or industrial systems.BACKGROUND

[0002] Complex technical systems, such as cellular or other communication networks or industrial systems, may automatically generate event records which may comprise plural indications, such as indications as to their origin, various technical values and identifiers of processes to which they relate. Such event records may be used to search for root causes of fault conditions in the system.

[0003] An example of an event record system is the Aircraft Communications Addressing and Reporting System, ACARS, which provides events from an aircraft to a ground station using a wireless link. These events include information on phases of a flight, air traffic control data as well as equipment health and maintenance data.SUMMARY

[0004] According to some aspects, there is provided the subject-matter of the independent claims. Some embodiments are defined in the dependent claims.

[0005] According to a first aspect of the present disclosure, there is provided an apparatus comprising at least one processing core and at least one memory storing instructions that, when executed by the at least one processing core, cause the apparatus at least to compile plural time series of event records based on plural technical characteristics of the event records, wherein the event records in a same time series share a same technicalcharacteristic from among the plural technical characteristics, the shared technical characteristic being a defining characteristic of the time series, the event records originating in a system, select, from among the plural time series, a set of time series, wherein each time series among the set of time series comprises at least one event record with a value determined by the apparatus to be anomalous or flagged as anomalous, compile an initial technical characteristic list by including in the initial technical characteristic list each defining characteristic of the time series in the set of time series, obtain a second technical characteristic list by removing from the initial technical characteristic list those technical characteristics which are defining characteristics of time series which satisfy a predetermined condition, and provide to at least one user an indication of the second technical characteristic list as an anomaly root cause candidate.

[0006] According to a second aspect of the present disclosure, there is provided a method comprising compiling plural time series of event records based on plural technical characteristics of the event records, wherein the event records in a same time series share a same technical characteristic from among the plural technical characteristics, the shared technical characteristic being a defining characteristic of the time series, the event records originating in a system, selecting, from among the plural time series, a set of time series, wherein each time series among the set of time series comprises at least one event record with a value determined to be anomalous or flagged as anomalous, compiling an initial technical characteristic list by including in the initial technical characteristic list each defining characteristic of the time series in the set of time series, obtaining a second technical characteristic list by removing from the initial technical characteristic list those technical characteristics which are defining characteristics of time series which satisfy a predetermined condition, and providing to at least one user an indication of the second technical characteristic list as an anomaly root cause candidate.

[0007] According to a third aspect of the present disclosure, there is provided a non- transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least compile plural time series of event records based on plural technical characteristics of the event records, wherein the event records in a same time series share a same technical characteristic from among the plural technical characteristics, the shared technical characteristic being a defining characteristic of the time series, the event records originating in a system, select, from among the plural time series, a set of time series,wherein each time series among the set of time series comprises at least one event record with a value determined by the apparatus to be anomalous or flagged as anomalous, compile an initial technical characteristic list by including in the initial technical characteristic list each defining characteristic of the time series in the set of time series, obtain a second technical characteristic list by removing from the initial technical characteristic list those technical characteristics which are defining characteristics of time series which satisfy a predetermined condition, and provide to at least one user an indication of the second technical characteristic list as an anomaly root cause candidate.

[0008] According to a fourth aspect of the present disclosure, there is provided a computer program configured to cause an apparatus to perform a method according to the second aspect, when run.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIGURE 1 illustrates an example system in accordance with at least some embodiments;

[0010] FIGURE 2 illustrates an example event record;

[0011] FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments of the present invention;

[0012] FIGURE 4 illustrates analysis of fault conditions in a system, and

[0013] FIGURE 5 is a flow graph of a method in accordance with at least some embodiments of the present invention.EMBODIMENTS

[0014] Disclosed herein are methods to enhance obtaining an increased situational awareness concerning fault conditions in a system, such as, for example, a cellular network or an industrial process, such as a power plant or manufacturing plant. In detail, event records are collected, each event record comprising a timestamp indicating a time that the event record relates to, and one or more technical indications, such as technical characteristics. The event records are assembled in time order and processed to assess which part, or parts, of the system are responsible for failures or sequences of failures inthe system. The aim is to identify root causes of faults to increase an effective utilization rate of the system, for example in terms of reduced downtime.

[0015] FIGURE 1 illustrates an example system in accordance with at least some embodiments. The example shown in FIGURE 1 is a cellular system, but the herein disclosed methods are not limited to being applied in a cellular context. FIGURE 1 illustrates a radio access network, RAN, 102, comprising plural base stations, which are configured to operate in accordance with a cellular communication standard, such as long term evolution, LTE, or fifth generation, 5G, also known as New Radio, NR, both as specified by the 3rdgeneration partnership project, 3GPP. Where a non-cellular system is used, access nodes, such as access points, corresponding to base stations of RAN 102 may be configured in accordance with a non-cellular communication standard such as wireless local area network, WLAN, or worldwide interoperability for microwave access, WiMAX, for example. In some embodiments, RAN 102 is absent, in these cases the network, NW, may be a wire-line network based on Ethernet, for example.

[0016] Base stations of RAN 102 are coupled with core network nodes of core network 103 via links, which may comprise wire-line connections, for example. A few such links are illustrated in FIGURE 1. Core network nodes 110, 120, 130, 140 and 150 may comprise mobility management entities, MME, serving gateways, S-GW, access and mobility management functions, AMF, subscriber information registers, policy enforcement entities, switching nodes and / or network exposure functions, for example. The core network may comprise a gateway 160, enabling communication with further networks, via at least one inter-network link. Some aggregate networks may have more than one core network, which are then connected to each other using at least one communication link.

[0017] Further, in the illustrated example situation, base stations of RAN 102 are in wireless radio communication with user equipments, UEs 101. Each UE may comprise, for example, a smartphone, feature phone, tablet or laptop computer, Intemet-of-Things, loT, node, smart wearable or a connected car connectivity module, for example. Naturally, separate UEs need not be of a same type. The UEs are configured to operate using a same cellular communication standard, or standards, as the base station(s), to obtain interoperability.

[0018] Core network nodes of core network 103 may be standalone physical nodes, running on a dedicated computing substrate, or they, or at least some of them, may be virtualized network nodes, such that more than one virtualized network node may run on a same physical computing substrate. Virtualized network nodes may be migrated from one physical computing substrate to another, for example to perform load balancing between the computing substrates, or to enable software or hardware updating of the computing substrates themselves. Another reason for migrating virtualized network nodes, or their traffic, is to enable repairs in physical hardware used to run the respective node. Core network 103 may comprise both standalone physical nodes and virtualized network nodes. In addition to the physical computing substrates, also virtualized and standalone physical nodes may be updated or re-configured. Re-configuring may comprise, for example, changing at least one operating parameter or updating to a different software version. Examples of operating parameters include traffic filters, prioritization rules, routing tables, routing policies and bandwidth caps affecting coverage areas, individual subscribers or subscriber classes.

[0019] Nodes of the system, such as RAN 102 nodes and core network nodes, may be configured to automatically, without user intervention, generate event records, which comprise a timestamp which indicates, in a time of the system or an external time reference, when the event record was generated. The event records further comprise indications of an event the record relates to. The event may be a benign or error event, wherein examples of benign events include new registrations of UEs into the system, successful handovers, measured interference levels and network utilization rates. Examples of error events include a dropped call, a failed UE authorization, a timed-out protocol connection, a failed network procedure, maximum capacity reached and a timed-out random access process. An example of a failed network procedure is a re-configuration process between core network 103 and a base station in RAN 102, which begins but which does not successfully complete, resulting in failure when a timer of the re-configuration process expires.

[0020] Event records comprise indications in the form of technical characteristics relating to the event, for example, they may comprise indications of a UE model or UE manufacturer, identifiers of one or more nodes participating in a process to which the event record relates. The event records include an event code which identifies the type of event, such as one of the afore-mentioned examples of events, for example. A single failure in thenetwork may cause a number of event records to be generated as a direct and / or indirect consequence. For example in case a base station fails completely, all protocol connections traversing the base station will be disconnected, causing a number of event records to be generated. Further, any attempts to re-configure the base station from the core network will also fail, causing yet further event records relating to errors. In such a case, the event records generated as a result may all share, among other indications, an identifier of the failed base station as one of the network elements involved in the error situation. This identifier may be used to collect these event records together, such that the identifier acts as a defining characteristic in the set of event records relating to the failure of the base station. These event records may then be set in a time order in a time series based on the timestamps of these event records, for example. The moment the base station failed will be observable in this time series as a time after which the number of error-type event records is greatly increased compared to the time period before this moment.

[0021] In this case it may be fairly simple to determine that the failure of the base station identified by the defining characteristic of the set of event records is the root cause of the fault condition, since this base station is suddenly no longer associated with benign event records and all of its event records as of the starting time of the fault condition are error-type event records. Further, the base station may be unresponsive to communications.

[0022] On the other hand if a radio unit of a base station develops a fault, this fault may have the consequence that a part, but not all, of communications via the base station fail. For example, some random access processes may time out, and some calls may be dropped but other random access processes and other calls via this base station may still succeed. Thus event records with the identity of this base station comprised therein will comprise both benign and error-type event records.

[0023] Further, an initial failure in one network element may cause error-type event records to be generated not only in the network element where the actual failure occurs, but also in other network elements. A single primary failure, root cause, in the network may cause plural secondary failures to occur such that the primary failure, being the root cause, may trigger a cascade of errors and error-type event records in several parts of the network. In light of a cascade of error-type event records, identifying the root cause may become challenging. This is the more so, since the earliest-timestamped error-type event record is not necessarily from the network element where the root cause occurs, and in fact thefailure itself may prevent that network element from even creating an event record. A typical real-world network incident manifests itself as a combination of several mathematical anomalies, such as failure counters and / or performance counters occurring at roughly the same time.

[0024] Yet further, a typical network has a continuing background level of error-type of event records which occur as a result of normal functioning of a communication network. The background level of errors may fluctuate as a response to varying use rates in the system. For example, UEs may exhaust their batteries, resulting in failures of radio resource control, RRC, connections, calls and other protocol connections involving this UE. Likewise other sporadic errors may occur throughout the network due to fluctuations in interference, spikes in network loading and controlled deactivation of network elements, such as for software updating, for example. The number of event records in realistically dimensioned networks is so large that manually analysing them by humans is often unrealistic.

[0025] Thus identifying root causes of errors in a technical system, such as a communication network or industrial process, is a challenge. Solving this challenge faster and at least in part, and possibly completely, automatically, provides the beneficial technical effect of faster and more accurate knowledge of the technical state of the system in terms of knowledge of root causes of failure conditions.

[0026] A goal in root cause identification is to identify a combination of technical characteristics that explains anomalies in the network. The anomalies may be expressed in terms of numerical variables, such as call drops, text message delivery failures and / or user data throughput, for example. Examples of technical characteristics include UE device type, UE device model, base station site, radio access technology, RAT, used, base station identity and core network node identity.

[0027] As a first phase of identifying the root cause, plural time series of event records from the system may be compiled based on plural technical characteristics of the event records, wherein all event records in a same time series comprise a same technical characteristic from among the plural technical characteristics. This shared technical characteristic thus becomes a defining characteristic of the time series. In other words, the time series each have event records which share a same technical characteristic, which then defines the time series as a series of event records which all have this technicalcharacteristic. The event records of each time series are ordered based on their respective timestamps to make the series a time series. A single event report may be present in more than one time series, since a single event report may comprise more than one technical characteristic. Examples of time series include evolution of call drops for smartphones and evolution of call drops for feature phones. Further examples of time series include evolution of call drops for 2G, 3G, 4G, and 5G, as well as evolution of call drops for postpaid, pre-paid and calling-card calls. The time series may also comprise event records which are benign. For example, a numerical variable “call drops” may be split into multiple time series by dividing its values into “call drops for 2G”, “call drops for 3G”, and “call drops for 4G”.

[0028] As a second phase of identifying the root cause, a set of time series is selected from among the plural time series, such that each time series in the selected set comprises at least one event record with a value determined or flagged as anomalous, or event record type which indicates an error-type event record. In other words, time series with only benign event records are not included in the selected set of time series. To increase a likelihood that root causes of independent anomalous events are not mixed up, individual time series in the selected set may initially be split to plural time series based on release reasons, such as error message types, such that each of the plural time series is characterized by an error message type. Thus “call drop” time series may be split to “call drop with error type 1” and “call drop with error type 2”, for example. In at least some embodiments, the split based on release reason is an initial split of the time series, from which other splits follow.

[0029] As a third phase of identifying the root cause, an initial technical characteristic list is obtained by including in the initial technical characteristic list each defining characteristic of the time series in the selected set of time series. In other words the initial technical characteristic list is a list of those technical characteristics which define those time series of event records which have at least one anomalous value, or event record type which indicates an error-type event record. The technical characteristics in the initial technical characteristic list are candidate filters to display or reveal the anomaly in a time series figure displayed to users.

[0030] As a fourth phase of identifying the root cause, a second technical characteristic list is obtained by removing from the initial technical characteristic list thosetechnical characteristics which are defining characteristics of time series which satisfy a predetermined condition. The technical characteristics remaining after this removal form the second technical characteristic list. The second technical characteristic list is a more accurate estimate of the set of technical characteristics identifying the root cause of failure than the initial technical characteristic list.

[0031] The predetermined condition may comprise, for example, that a specific time series has anomalous values which contribute a same, within a preconfigured tolerance limit, contribution to overall anomalous values of the system during anomalous and non- anomalous times. In other words, if post-paid subscriptions represent 70% of call drops during both anomalous and non-anomalous times, then this technical characteristic may be excluded from the second technical characteristic list. A point in time is determined to be anomalous for a specific time series when numerical values in event records of the specific time series are determined to be anomalous by comparing these values to predicted values. Values may be in this sense predicted based on nominal performance parameters, machine learning processes or previously recorded events sequences which have been observed to not result in errors.

[0032] The first four phases may be repeated at a constant time interval, which may be five minutes, six minutes or eight minutes, for example.

[0033] As a fifth phase of identifying the root cause, matching is performed to determine, whether the second technical characteristic list represents an already known or ongoing anomaly or fault state of a segment of the system. That is, the matching comprises determining if the second technical characteristic list is a characteristic list of an already known or ongoing anomaly or fault state of a segment of the system. If this is not the case, then a novel fault state appears to have been identified by the second technical characteristic list, which may be indicated to users of the system using a graphical user interface, or via audio signalling, for example.

[0034] In at least some embodiments, the identification of the root cause relates to anomalies in a specific numerical performance variable of the system, such as call drop rate or user data throughput shortcoming. In these embodiments, for example in the second phase, a deviation size may be determined for this performance variable, indicating by how much the performance variable deviates from a nominal value. In these embodiments, the predetermined condition may comprise that that a specific time series contributes less thana pre-set limit relative contribution to the deviation size. That is, if the time series contributes less than a pre-determined fraction of the deviation size, then its defining characteristic may be excluded from the second technical characteristic list. Likewise the predetermined condition may be that a specific time series has anomalous values which contribute a same, within a preconfigured tolerance limit, contribution to the numerical performance variable of the system during anomalous and non-anomalous times. The matching may be based on correlating the second technical characteristic list with an identified root cause of the already known fault state. The matching is conducted to discover, if the anomaly in the present time is a newly beginning anomaly, or a continuing anomaly which has begun previously.

[0035] As an example of the matching, the matching may be based on determining whether technical characteristics comprised in the second technical characteristic list are defining characteristics of time series which have anomalous values in event records with timestamps which indicate times when the already known fault state causes anomalous behaviour in the system. In other words, the matching is in this example used to determine, whether error-type event records in the time series defined by the technical characteristics in the second technical characteristic list occur at the same time as performance problems caused by the already known fault state.

[0036] Further concerning the matching, a user or a network matching may be performed, wherein the match is pre-configured depending on the suspected root cause potentially derived from the error message returned by the failing protocol, that is, the release reason. For example, user matching may be performed based on device type, model, etc. to identify how an anomaly is caused by some specific device type or operating system. In this case, common network-side values become irrelevant. Network matching may be performed based on network node identities. The strength of the match may be predefined, wherein a weak match preserves technical characteristics which disappear 50% of the time, while a strong match only keeps technical characteristics that are always present. An example of match strength assessment: A cell group is not experiencing problems for one 5-min interval out of twenty such intervals, therefore is removed from the root cause.

[0037] Values in event records may be determined to be anomalous by comparing the values to predicted values, and determining the values as anomalous in case they differby more than a preconfigured amount from the predicted values. The predicting may be based on historical values and predetermined models of expected value behaviour.

[0038] FIGURE 2 illustrates an example event record. Event record 210 comprises technical characteristics 222, 224, 226 which relate to the event recorded in event record 210. For example, these may be a UE type of a UE involved in the event, a UE make of this UE, a base station identity involved in the event, a frequency range used, and / or one or more core network node identifier(s) involved in the event. The number of technical characteristics is not limited to three, but may be less than three or more than three. For example, there may be plural technical characteristics in event record 210.

[0039] Further, event record 210 of FIGURE 2 comprises an event identifier 230, which indicates what type of event the event record relates to. As described above, examples include random access process success or failure, registration of a UE in the network, and a dropped call. Further, event record 210 of FIGURE 2 comprises timestamp 240, which indicates, for example in an internal time of the system or in a time derived from an external source, such as positioning satellite constellation, for example, a time instant when the event was recorded by a node which generates the event record. This corresponds to a time instant when the event occurred and when event record 210 was generated. Finally, optionally, event record 210 may comprise an indication 250 as to whether the event is benign or an error.

[0040] FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments of the present invention. Illustrated is device 300, which may comprise, for example, a node configured to determine the root cause. Comprised in device 300 is processor 310, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core. Processor 310 may comprise, in general, a control device. Processor 310 may comprise more than one processor. When processor 310 comprises more than one processor, device 300 may be a distributed device wherein processing of tasks takes place in more than one physical unit. Processor 310 may be a control device. A processing core may comprise, for example, a Cortex- A8 processing core manufactured by ARM Holdings or a Zen processing core designed by Advanced Micro Devices Corporation. Processor 310 may comprise at least one AMD Opteron and / or Intel Core or Xeon processor. Processor 310 may comprise at least one application-specificintegrated circuit, ASIC. Processor 310 may comprise at least one field-programmable gate array, FPGA. Processor 310 may be means for performing method steps in device 300. Processor 310 may be configured, at least in part by computer instructions, to perform actions.

[0041] Device 300 may comprise memory 320. Memory 320 may comprise randomaccess memory and / or permanent memory. Memory 320 may comprise at least one RAM chip. Memory 320 may be a computer readable medium. Memory 320 may comprise solid- state, magnetic, optical and / or holographic memory, for example. Memory 320 may be at least in part accessible to processor 310. Memory 320 may be at least in part comprised in processor 310. Memory 320 may be means for storing information. Memory 320 may comprise computer instructions that processor 310 is configured to execute. When computer instructions configured to cause processor 310 to perform certain actions are stored in memory 320, and device 300 overall is configured to run under the direction of processor 310 using computer instructions from memory 320, processor 310 and / or its at least one processing core may be considered to be configured to perform said certain actions. Memory 320 may be at least in part comprised in processor 310. Memory 320 may be at least in part external to device 300 but accessible to device 300. Memory 320 may be transitory or non-transitory. The term “non-transitory”, as used herein, is a limitation of the medium itself (that is, tangible, not a signal) as opposed to a limitation on data storage persistency (for example, RAM vs. ROM).

[0042] Device 300 may comprise a transmitter 330. Device 300 may comprise a receiver 340. Transmitter 330 and receiver 340 may be configured to transmit and receive information, respectively.

[0043] Device 300 may comprise user interface, UI, 360. UI 360 may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device 300 to vibrate, a speaker or a microphone. A user may be able to operate device 300 via UI 360, for example to configure fault management parameters and / or event record storage policies.

[0044] Processor 310 may be furnished with a transmitter arranged to output information from processor 310, via electrical leads internal to device 300, to other devices comprised in device 300. Such a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 320 forstorage therein. Alternatively to a serial bus, the transmitter may comprise a parallel bus transmitter. Likewise processor 310 may comprise a receiver arranged to receive information in processor 310, via electrical leads internal to device 300, from other devices comprised in device 300. Such a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from receiver 340 for processing in processor 310. Alternatively to a serial bus, the receiver may comprise a parallel bus receiver.

[0045] Processor 310, memory 320, transmitter 330, receiver 340, and / or UI 360 may be interconnected by electrical leads internal to device 300 in a multitude of different ways. For example, each of the aforementioned devices may be separately connected to a master bus internal to device 300, to allow for the devices to exchange information. However, as the skilled person will appreciate, this is only one example and depending on the embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.

[0046] FIGURE 4 illustrates analysis of fault conditions in a system. Graph 410 illustrates an overall error occurrence frequency in the system, such as cellular network, for example. Time advances, in all the graphs of FIGURE 4, from the left to the right and error frequency increases from the bottom toward the top. As can be seen in graph 410, the error frequency is stable in the system until at the right, it suddenly increases. The sudden increase suggests that a new fault state has occurred in the system, and discovering its root cause is of interest.

[0047] Graphs 420, 430, 440 and 450 correspond to time series of event records defined by a technical characteristic, as described herein above. In detail, graph 420 is defined by the technical characteristic RAT = 4G. Graph 430 is defined by the technical characteristic base station identity = 32181. Graph 440 is defined by the technical characteristic RAT = 2G. Graph 440 is defined by the technical characteristic that a roaming subscriber is involved, that is, a subscriber that is outside its home network.

[0048] FIGURE 4 illustrates operation of the fourth phase of identifying the root cause. As can be seen, graphs 420 and 430 have an increased frequency of error-type event records at the same time as the system- wide graph 410. It is thus plausible, that these defining characteristics, RAT = 4G and base station id = 32181, are involved in the root cause of the fault. On the other hand graph 440 does not display any increased frequencyof errors at the time the system displays the error peak in graph 410, wherefore it seems that technical characteristic RAT = 2G is not associated with the root cause. Finally, graph 450 does not have an error peak at all and it seems that its event records are not affected by the new fault condition. Technical characteristic subscriber roaming thus may be excluded from the second technical characteristic list.

[0049] Time series defined by characteristics not in the root cause may have an uptick of error frequency when the system-wide error frequency increases, since the system- wide error frequency increase may affect many groups of nodes and users. However, this uptick is less than in time series which are in the root cause, since the root cause will affect all event records in the time series included in the root cause, and only a subset and not all of event records defined by different characteristics.

[0050] FIGURE 5 is a flow graph of a method in accordance with at least some embodiments of the present invention. The phases of the illustrated method may be performed in an anomaly management node or in a control device configured to control the functioning thereof, when installed therein.

[0051] Phase 510 comprises compiling plural time series of event records based on plural technical characteristics of the event records, wherein the event records in a same time series share a same technical characteristic from among the plural technical characteristics, the shared technical characteristic being a defining characteristic of the time series, the event records originating in a system. Phase 520 comprises selecting, from among the plural time series, a set of time series, wherein each time series among the set of time series comprises at least one event record with a value determined to be anomalous or flagged as anomalous. Phase 530 comprises compiling an initial technical characteristic list by including in the initial technical characteristic list each defining characteristic of the time series in the set of time series. Phase 540 comprises obtaining a second technical characteristic list by removing from the initial technical characteristic list those technical characteristics which are defining characteristics of time series which satisfy a predetermined condition. Finally, phase 550 comprises providing to at least one user an indication of the second technical characteristic list as an anomaly root cause candidate.

[0052] It is to be understood that the embodiments of the invention disclosed are not limited to the particular structures, process steps, or materials disclosed herein, but are extended to equivalents thereof as would be recognized by those ordinarily skilled in therelevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular embodiments only and is not intended to be limiting.

[0053] Reference throughout this specification to one embodiment or an embodiment means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Where reference is made to a numerical value using a term such as, for example, about or substantially, the exact numerical value is also disclosed.

[0054] As used herein, a plurality of items, structural elements, compositional elements, and / or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and example of the present invention may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations of the present invention.

[0055] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the preceding description, numerous specific details are provided, such as examples of lengths, widths, shapes, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

[0056] While the forgoing examples are illustrative of the principles of the present invention in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention. Accordingly, it is not intended that the inventionbe limited, except as by the claims set forth below.

[0057] The verbs “to comprise” and “to include” are used in this document as open limitations that neither exclude nor require the existence of also un-recited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated. Furthermore, it is to be understood that the use of "a" or "an", that is, a singular form, throughout this document does not exclude a plurality.

[0058] As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.INDUSTRIAL APPLICABILITY

[0059] At least some embodiments of the present invention find industrial application in network management.

Claims

CLAIMS:

1. An apparatus (300) comprising at least one processing core (310) and at least one memory (320) storing instructions that, when executed by the at least one processing core (310), cause the apparatus (300) at least to:- compile plural time series (420, 430, 440, 450) of event records (210) based on plural technical characteristics (222, 224, 226) of the event records (210), wherein the event records (210) in a same time series (420, 430, 440, 450) share a same technical characteristic (222, 224, 226) from among the plural technical characteristics (222, 224, 226), the shared technical characteristic (222, 224, 226) being a defining characteristic of the time series (420, 430, 440, 450), the event records (210) originating in a cellular communication network, each technical characteristic (222, 224, 226) being selected from the list: user equipment device type, user equipment device model, base station site, radio access technology used, base station identity and core network node identity;- select, from among the plural time series (420, 430, 440, 450), a set of time series, wherein each time series (420, 430, 440, 450) among the set of time series comprises at least one event record (210) with a value determined by the apparatus (300) to be anomalous or flagged as anomalous;- compile an initial technical characteristic list by including in the initial technical characteristic list each defining characteristic of the time series (420, 430, 440, 450) in the set of time series;- obtain a second technical characteristic list by removing from the initial technical characteristic list those technical characteristics (222, 224, 226) which are defining characteristics of time series (420, 430, 440, 450) which contribute less than a preset limit relative contribution to all anomalous behaviour of the cellular communication network, and- provide to at least one user an indication of the second technical characteristic list as an anomaly root cause candidate.

2. The apparatus (300) according to claim 1, wherein the apparatus (300) is configured to determine that values in event records (210) are anomalous by comparing the values topredicted values, and determining the values as anomalous in case they differ by more than a preconfigured amount from the predicted values.

3. The apparatus (300) according to claim 2, further configured to perform the predicting based on historical values and predetermined models of expected value behaviour.

4. The apparatus (300) according to any of claims 1 - 3, wherein the apparatus (300) is configured to perform matching to determine, whether the second technical characteristic list represents an already known fault state of a segment of the cellular communication network.

5. The apparatus (300) according to claim 4, wherein the matching is based on correlating the second technical characteristic list with an identified root cause of the already known fault state.

6. The apparatus (300) according to claim 4 or 5, wherein the matching is based on determining whether technical characteristics (222, 224, 226) comprised in the second technical characteristic list are defining characteristics of time series (420, 430, 440, 450) which have anomalous values in event records (210) with timestamps which indicate times when the already known fault state causes anomalous behaviour in the cellular communication network.

7. A method comprising:- compiling plural time series (420, 430, 440, 450) of event records (210) based on plural technical characteristics (222, 224, 226) of the event records (210), wherein the event records (210) in a same time series (420, 430, 440, 450) share a same technical characteristic (222, 224, 226) from among the plural technical characteristics (222, 224, 226), the shared technical characteristic (222, 224, 226) being a defining characteristic of the time series (420, 430, 440, 450), the event records (210) originating in a cellular communication network, each technical characteristic (222, 224, 226) being selected from the list: user equipment device type, user equipment device model, base station site, radio access technology used, base station identity and core network node identity;- selecting, from among the plural time series (420, 430, 440, 450), a set of time series, wherein each time series (420, 430, 440, 450) among the set of time series comprises at least one event record (210) with a value determined to be anomalous or flagged as anomalous;- compiling an initial technical characteristic list by including in the initial technical characteristic list each defining characteristic of the time series (420, 430, 440, 450) in the set of time series;- obtaining a second technical characteristic list by removing from the initial technical characteristic list those technical characteristics (222, 224, 226) which are defining characteristics of time series (420, 430, 440, 450) which contribute less than a pre-set limit relative contribution to all anomalous behaviour of the cellular communication network, and- providing to at least one user an indication of the second technical characteristic list as an anomaly root cause candidate.

8. The method according to claim 7, wherein the method comprises performing the determining that values in event records (210) are anomalous by comparing the values to predicted values, and determining the values as anomalous in case they differ by more than a preconfigured amount from the predicted values.

9. The method according to claim 8, comprising performing the predicting based on historical values and predetermined models of expected value behaviour.

10. The method according to any of claims 7 - 9, comprising performing matching to determine, whether the second technical characteristic list represents an already known fault state of a segment of the cellular communication network.

11. The method according to claim 10, wherein the matching is based on correlating the second technical characteristic list with an identified root cause of the already known fault state.

12. The method according to claim 10 or 11, wherein the matching is based on determining whether technical characteristics (222, 224, 226) comprised in the second technicalcharacteristic list are defining characteristics of time series (420, 430, 440, 450) which have anomalous values in event records (210) with timestamps which indicate times when the already known fault state causes anomalous behaviour in the cellular communication network.

13. A non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor (310), cause an apparatus (300) to at least:- compile plural time series (420, 430, 440, 450) of event records (210) based on plural technical characteristics of the event records (210), wherein the event records (210) in a same time series (420, 430, 440, 450) share a same technical characteristic from among the plural technical characteristics, the shared technical characteristic being a defining characteristic of the time series (420, 430, 440, 450), the event records (210) originating in a cellular communication network, each technical characteristic being selected from the list: user equipment device type, user equipment device model, base station site, radio access technology used, base station identity and core network node identity;- select, from among the plural time series(420, 430, 440, 450), a set of time series, wherein each time series (420, 430, 440, 450) among the set of time series comprises at least one event record (210) with a value determined by the apparatus (300) to be anomalous or flagged as anomalous;- compile an initial technical characteristic list by including in the initial technical characteristic list each defining characteristic of the time series (420, 430, 440, 450) in the set of time series;- obtain a second technical characteristic list by removing from the initial technical characteristic list those technical characteristics which are defining characteristics of time series (420, 430, 440, 450) which contribute less than a pre-set limit relative contribution to all anomalous behaviour of the cellular communication network, and- provide to at least one user an indication of the second technical characteristic list as an anomaly root cause candidate.

Images