Patent Description:
A network operation center (NOC) is generally a location from which NOC personnel exercises monitoring and control over a network. NOC personnel are responsible for monitoring one or many networks for certain conditions that may require special attention to avoid degraded service. NOC personnel follow screens showing events received from network devices, ongoing incidents and general network performance. NOC personnel decide upon required actions based on information they see on the screens.

Automation of NOC functionality of telecommunication networks has been developed in order to improve efficiency of network monitoring and control and to reduce the amount of manual work and human errors. But automation of network monitoring and control is not a straightforward task to implement.

<CIT> relates to automated handling of alarms for a telecommunications network. Automated actions are defined for alarms. However, if there are any contrary instructions in the database, no action is initiated.

The present invention is defined in the method of independent claim <NUM>, in the apparatus of independent claim <NUM>, in the computer program of independent claim <NUM>, and in the methods of dependent claims <NUM>-<NUM>.

According to a first example aspect of the present invention, there is provided a computer implemented method of network monitoring and according to claim <NUM>.

In an embodiment, the method further comprises checking, after a predefined period of time, whether the identified alert has reappeared and responsively taking a further action.

In an embodiment, the identified alert indicates degraded performance in the group of monitored devices, faulty or degraded operation in the group of monitored devices and/or a change in external conditions.

In an embodiment, identifying the alert comprises obtaining performance data related to monitored devices, and identifying the alert based on the performance data and performance rules.

In an embodiment, the method further comprises identifying the alert based on one or more thresholds being exceeded in the performance data.

In an embodiment, the method further comprises identifying that a ticket associated with the monitored device exists and enriching the ticket based on the identified alert.

In an embodiment, the method further comprises identifying that the monitored device is in a quarantine list and responsively terminating processing of the identified alert.

In an embodiment, the method further comprises identifying that the monitored device is under maintenance or that a rollout is being performed in the monitored device and responsively terminating processing of the identified alert.

In an embodiment, the method further comprises identifying that a monitored device specific threshold or a system specific threshold has been exceeded and responsively terminating processing of the identified alert.

In an embodiment, the method further comprises identifying that the identified alert has reappeared and responsively generating a ticket for manual handling.

In an embodiment, the automatic action is an action affecting operation of the monitored device.

In an embodiment, the automatic action comprises one or more of the following: resetting the monitored device, changing value of at least one parameter in the network device, closing a port in the monitored device, opening a port in the monitored device, and automatically generating a ticket for manual action.

According to a second example aspect of the present invention, there is provided an apparatus comprising a processor and a memory including computer program code; the memory and the computer program code configured to, with the processor, cause the apparatus to perform the method of the first aspect or any related embodiment.

According to a third example aspect of the present invention, there is provided a computer program comprising computer executable program code which when executed by a processor causes an apparatus to perform the method of the first aspect or any related embodiment.

The computer program of the third aspect may be a computer program product stored on a non-transitory memory medium.

Example embodiments of the present invention and its potential advantages are understood by referring to <FIG> of the drawings. In this document, like reference signs denote like parts or steps.

In an embodiment of the invention there is provided an automated network monitoring and control system. The developed automated solution can be employed in NOC functionality of a telecommunication network. Additionally or alternatively, the developed automated solution can be employed in monitoring and control of devices of a power grid or of devices of a cable or television network or some other group of monitored devices. In general, the developed automated solution can be employed for monitoring and control of any electronic devices that are communicatively connected to a network monitoring and control system implementing the automated solution. Various embodiments of the invention discussed in the following relate to monitoring of a telecommunication network, but it is to be understood that disclosed embodiments may be applied to other monitored devices, too. A monitored device in the sense of present disclosure can be any electronic device that is being monitored and/or controlled. It is to be noted that the group of monitored devices may be part of a larger system comprising also devices that are not being monitored. For example a telecommunication network may comprise a plurality of devices that are not being monitored or controlled through the present automated solution.

As operational load and network complexity increase due to increasing number of base stations and other network devices as well as increasing amount of manual work required for maintaining quality of network, there is increasing need for automation of network monitoring and control of telecommunication networks. At the same time the need for automated monitoring increases in other application areas, too.

<FIG> shows an example scenario according to an embodiment. The scenario shows a group of monitored devices <NUM> and an automated monitoring and control system <NUM>. Alerts related to the monitored devices <NUM> are conveyed to the automated monitoring and control system <NUM> in phase <NUM>. The cause for generation of an alert may be for example a fault in a monitored device such as one or more of the following: abnormal behaviour of a monitored device, hardware failure in a monitored device, exceeding a predefined threshold, synchronization problem, failure in operation of a functionality, excess load, insufficient storage capacity, insufficient processing resources, degraded performance etc. Performance of the monitored device or the whole system comprising the monitored device may be based on suitable performance indicators. The performance indicators may comprise for example counter values and/or Key Performance Indicator, KPI, values derived on the basis of one or more other performance indicators. In an example implementation, the performance indicators are observed over a predefined time and, if needed, an alert is generated on the basis of the observations. Additionally or alternatively, in a telecommunication network the cause for generation of an alert may be for example one or more of the following: abnormal behaviour of a base station, transmission problem in a network link, existence of an SNMP (Simple Network Management Protocol) trap, degraded throughput etc. Additionally or alternatively, the source of the alert may be an external system, such as a weather database or a traffic data source or a call data record (CDR) database.

The automated monitoring and control system <NUM> analyses the alerts in <NUM> to automatically decide on actions to be taken. The automatically decided actions are performed on one or more monitored devices in phase <NUM>. It is to be noted that the action is decided and performed autonomously without human interaction. Furthermore, it is to be noted that the device originating the alert may be different from the device in which the automated action is applied. Additionally or alternatively, the automatically decided action may be generation of a ticket for manual action. In this case human actions may be used for solving the issue. The shown process is continuously repeated. Additionally, if the fault causing the alert(s) is not fixed by the automatic action and/or the alert reappears, a ticket for manual action may be generated.

<FIG> shows a system according to an embodiment. The system comprises a telecommunication network <NUM>, user devices <NUM>, cloud and service platforms <NUM> and Internet <NUM>. The telecommunication network <NUM> serves user devices <NUM> connected to the telecommunication network <NUM>. The telecommunication network <NUM> provides communication services to the user devices such as for example access to cloud and service platforms <NUM> and Internet <NUM> and other systems. The telecommunication network <NUM> may be divided into a radio access network <NUM> comprising base stations that provide radio interface for connecting to the telecommunication network <NUM>, a backhaul portion <NUM> that connects the radio interface of the radio access network <NUM> to other parts of the network, IP/MPLS (Internet Protocol / Multiprotocol Label Switching) portion <NUM> that provides data-carrying services for both circuit switched and packet switched communications, a circuit switched core network <NUM> for circuit switched communications and a packet switched core network <NUM> for packet switched communications.

Further the system of <FIG> comprises an OSS (Operations Support System) <NUM> and an automated monitoring and control system <NUM>. The OSS continuously collects alerts from one or more monitored devices of the telecommunication network <NUM>. For example hardware failure in a base station of the radio access network <NUM> causes generation of an alert that is then conveyed to the OSS. The alerts received in the OSS are conveyed to the automated monitoring and control system <NUM>. The automated monitoring and control system <NUM> analyses the alerts to automatically decide on actions that may be required. The action may be an automatic action <NUM> performed on one or more monitored devices of the telecommunication network, such as resetting a monitored device, changing value of at least one parameter in a monitored device, closing a port in a monitored device, or opening a port in a monitored device. Alternatively or additionally the action may be generation of an alert ticket for manual action.

<FIG> shows logical components of an example system suited for implementing certain embodiments. The system is divided into a hardware supervision block <NUM>, a performance supervision block <NUM>, a predictive supervision block <NUM> and a manual actions block <NUM>. The hardware supervision block <NUM> concerns collecting and analyzing <NUM>, <NUM> alerts received from physical monitored devices, and automatically deciding and performing actions based on the analysis <NUM> and possibly generating tickets for manual actions <NUM>. The performance supervision block <NUM> concerns collecting and analyzing performance data related to monitored devices <NUM>, <NUM>, and automatically deciding and performing actions based on the analysis <NUM> and possibly generating tickets for manual actions <NUM>. The predictive supervision block <NUM> concerns collecting <NUM> data from the monitored devices, the data comprising for example alerts and/or performance data, and predicting forthcoming alerts or incidents based on collected data <NUM>. The predicted alerts or incidents are then used for deciding and performing actions <NUM> and possibly for generating tickets for manual actions <NUM>. The manual actions block <NUM> concerns manually performed work, such as <NUM>: handling of tickets relating to customer complaints and <NUM>: handling of tickets generated by the automatic process of one of the blocks <NUM>-<NUM>. It is to be noted that data for the hardware supervision, performance supervision and predictive supervision blocks <NUM>, <NUM>, <NUM> may be collected from other external sources, too. Certain embodiments of present invention relate mainly but not exclusively to the hardware supervision block <NUM> and the performance supervision block <NUM>.

<FIG> show flow diagrams illustrating example methods according to certain embodiments. The methods may be implemented in the automated monitoring and control system <NUM> of <FIG> and <FIG>. The methods are implemented in a computer and do not require human interaction. It is to be noted that the methods may however provide output that may be further processed by humans. The methods of <FIG> may be combined with each other and the order of phases conducted in each method may be changed expect where otherwise explicitly defined. Furthermore it is to be noted that performing all phases of the flow charts is not mandatory.

<FIG> shows a flow diagram illustrating a method according to an embodiment of the invention. The method comprises following phases:.

Phase <NUM>: An alert related to a monitored device is identified. The alerts may be alerts concerning faults in operation of monitored devices. The faults may concern hardware problems, unavailable services or degraded performance as discussed in connection with <FIG>. Additionally or alternatively the source of alerts may be an external source, such as weather database or traffic surveillance database. In an embodiment, phase <NUM> comprises filtering the alerts that are being processed to reduce the number of alerts in further processing and/or classifying the alerts to different categories.

Phase <NUM>: It is checked whether an automatic action can be applied to the monitored device. In general this refers to checking whether performing an automatic action would interfere with some other ongoing action or whether there is some other matter that indicates the automatic action should be avoided. More detailed embodiments relating to performing this phase are discussed in connection with <FIG>. In an embodiment the checking of applicability of the automatic actions if performed by checking that a ticket associated with the monitored device does not exist, and that automatic actions do not interfere with ongoing actions being performed in the monitored device. Additionally it may be checked that the monitored device is not in a quarantine list. If it is concluded that automatic actions are not applicable, processing of the identified alert is terminated in phase <NUM>. A report of the identified alert may be generated, though. Additionally or alternatively, a ticket for manual operations may be generated so that human intervention is possible if needed. If it is concluded that automatic actions are applicable, the process proceeds to phase <NUM>. By checking applicability of automatic actions, one achieves that risk of automatically performing unnecessary or even harmful actions can be reduced. This is beneficial in connection with any alert, but especially alerts concerning degraded performance might cause unnecessary actions to be taken if such checking phase was not performed.

Phase <NUM>: An action is performed for the monitored device based on the identified alert. The action may be chosen for example based on predefined rules or predefined logic charts. It is to be noted that more than one alert related to the monitored device may have been identified and the action may be chosen on the basis of more than one identified alert. That is, there may be a certain alert pattern that leads to a certain action, while one single alert may lead to another action. It is to be noted that in this context an action may comprise a single action or more than one actions.

Phase <NUM>: The process waits for a predefined period of time. This may be for example <NUM>, <NUM>, <NUM>, <NUM> or an hour.

Phase <NUM>: It is checked whether the fault causing the alert identified in phase <NUM> was fixed. In an example embodiment this is implemented by checking if the identified alert reappears. If the fault was fixed, the process stops in phase <NUM> and a report is generated to log the action that was taken by the automatic process. If the fault was not fixed, a ticket for manual action is generated in phase <NUM>. Alternatively or additionally, the process may return to phase <NUM> to repeat the action for the monitored device. Yet another alternative (not shown in <FIG>) is to perform for the monitored device another action different from the action performed in phase <NUM>.

By checking whether the alert reappears and generating a ticket for manual action if necessary, one achieves that the automatic system does not continue to perform the automatic action forever, if the action is not fixing the problem.

In an embodiment the alert that is identified in phase <NUM> is a cell faulty alert in a telecommunication network and the action that is performed in phase <NUM> is resetting the monitored device (the monitored device may be for example a base station). For example existence of one or more of the following alerts may be considered a cell faulty alert: monitored device disconnected, base station down, cell out of service, cell unavailable, and transmission interruption.

Other embodiments comprise the following different embodiments:.

<FIG> shows a flow diagram illustrating a method according to an embodiment of the invention. The method is one example implementation of phase <NUM> of <FIG>. The method comprises following phases:.

Phase <NUM>: Performance data concerning a predefined period of time is obtained. The predefined time may be for example <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> or a day. The performance data may comprise counter values, transmission or throughput rates or other performance indicators. As an example, a counter may count for example number of dropped connections. Additionally or alternatively the performance data may comprise a performance value derived on the basis of more than one counter values.

Phase <NUM>: The performance data is compared to performance rules or decision logic.

Phase <NUM>: One or more alerts are identified on the basis of the comparison phase <NUM>.

Phase <NUM>: An alert related to a monitored device is identified similarly to <FIG>.

In phases <NUM>, <NUM>, <NUM> and <NUM> it is checked whether an automatic action can be applied to the monitored device.

Phase <NUM>: It is checked whether a ticket associated with the monitored device already exists. That is, it is checked if a problem associated with the monitored device has already been identified. If it is found out that a ticket already exists, the ticket is enriched with information about the identified alert in phase <NUM>. Otherwise the process proceeds to phase <NUM>.

Phase <NUM>: It is checked whether the monitored device is in a quarantine list. If it is found out that the monitored device is in a quarantine list, processing of the identified alert is terminated in phase <NUM>. A report of the identified alert may be generated. Otherwise the process proceeds to phase <NUM>. In an embodiment, a monitored device is inserted into a quarantine list whenever certain automatic action (e.g. reset) is being performed in the monitored device and the monitored device is kept on the list for a period of time that may be for example <NUM>, <NUM> or <NUM> days or <NUM>, <NUM>, <NUM> or <NUM> weeks. During this time further automatic actions are prevented in the monitored device. In this way the checking phase <NUM> provides that the automatic action is not continuously repeated for the monitored device. The quarantine list may indicate which alert caused the quarantine and this may be taken into account when checking whether the monitored device is in the quarantine list.

Phase <NUM>: It is checked whether a rollout process is being performed in the monitored device. If it is found out that there is a rollout in progress, processing of the identified alert is terminated in phase <NUM>. A report of the identified alert may be generated. Otherwise the process proceeds to phase <NUM>.

Phase <NUM>: It is checked whether the monitored device is in maintenance. If it is found out that there is a maintenance work in progress, processing of the identified alert is terminated in phase <NUM>. A report of the identified alert may be generated. Otherwise the process proceeds to phase <NUM>.

Phases <NUM> and <NUM> provide that automatic actions do not interfere with any ongoing actions being performed in the monitored device. Also phase <NUM> provides that automatic actions do not interfere with any ongoing actions being performed in the monitored device.

Phase <NUM>: An action is performed for the monitored device based on the identified alert. The action may be chosen for example based on predefined rules or predefined logic charts. It is to be noted that more than one alert related to the monitored device may have been identified and the action may be chosen on the basis of more than one identified alert. That is, there may be a certain alert pattern that leads to a certain action, while one single alert may lead to another action. It is to be noted that in this context an action may comprise a single action or more than one actions. By checking whether a ticket associated with the monitored device already exists and that automatic actions do not interfere with any ongoing actions being performed in the monitored device and performing any automated actions only after passing these checks, one achieves a comprehensive check on whether there is an indication of that the automated correction might not be desirable. In this way, one achieves reducing the probability of performing unnecessary automated actions.

In an embodiment, the process proceeds from phase <NUM> to phases <NUM>-<NUM> as disclosed in <FIG>.

Phase <NUM>: It is detected that a monitored device is in a quarantine list for example as a result of the checking in phase <NUM> of <FIG>.

Phase <NUM>: It is checked how many times the quarantine list has been violated and whether a threshold is being exceeded. Violation of the quarantine list refers to that the process tries to perform an automatic action for a monitored device that is listed on the quarantine list. The number of such violations is logged. The threshold may be for example <NUM>, <NUM>, <NUM> or <NUM> violations per monitored device. The threshold may be alert specific. That is, a different counter may be maintained for different alerts. Counter of the violations is reset when the network device is removed from the quarantine list.

If the threshold has been exceeded, a ticket for manual action is generated in phase <NUM>. In this way human interaction is provided for solving the reason for repeated requests for automatic actions. If the threshold has not been exceeded, processing of the alert identified for the monitored device is terminated in phase <NUM> and the quarantine list violation counter is incremented.

In phases <NUM> and <NUM> it is checked whether an automatic action can be applied to the monitored device.

Phase <NUM>: It is checked whether a monitored device specific threshold has been exceeded. If it is found out that the threshold has been exceeded, processing of the identified alert is terminated in phase <NUM>. A report of the identified alert may be generated. Otherwise the process proceeds to phase <NUM>. The threshold may be for example at least <NUM>% or <NUM>% degradation in performance compared to previous performance values. The checking phase <NUM> provides that the automatic actions can be controlled on a monitored device level and for example performing ineffective actions can be reduced. Performance may be degraded from optimal, but if there has not been a significant change compared to previous values, corrective actions may not be required or may not be effective.

Phase <NUM>: It is checked whether a network specific or a system specific threshold has been exceeded. If it is found out that the threshold has been exceeded, processing of the identified alert is terminated in phase <NUM>. A report of the identified alert may be generated. Otherwise the process proceeds to phase <NUM>. The threshold may be for example maximum <NUM>, <NUM> or <NUM> actions per day. The checking phase <NUM> provides that the automatic actions can be controlled on a network or system level and for example resetting all monitored devices of a system at the same time can be prevented.

Phase <NUM>: An action is performed for the monitored device based on the identified alert. The action may be chosen for example based on predefined rules or predefined logic charts. It is to be noted that more than one alert related to the network device may have been identified and the action may be chosen on the basis of more than one identified alert. That is, there may be a certain alert pattern that leads to a certain action, while one single alert may lead to another action. It is to be noted that in this context an action may comprise a single action or more than one actions. Network device specific or network specific counter may be increment after the automatic action has been performed.

<FIG> shows an apparatus <NUM> according to an embodiment. The apparatus <NUM> is for example a general-purpose computer or server or some other electronic data processing apparatus. The apparatus <NUM> can be used for implementing embodiments of the invention. That is, with suitable configuration the apparatus <NUM> is suited for operating for example as the network monitoring and control system <NUM> of foregoing disclosure.

The general structure of the apparatus <NUM> comprises a processor <NUM>, and a memory <NUM> coupled to the processor <NUM>. The apparatus <NUM> further comprises software <NUM> and database <NUM> stored in the memory <NUM> and operable to be loaded into and executed in the processor <NUM>. The software <NUM> may comprise one or more software modules and can be in the form of a computer program product. The database <NUM> may be usable for storing e.g. rules and patterns for use in data analysis. Further, the apparatus <NUM> comprises a communication interface <NUM> coupled to the processor <NUM>.

The processor <NUM> may comprise, e.g., a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a graphics processing unit, or the like. <FIG> shows one processor <NUM>, but the apparatus <NUM> may comprise a plurality of processors.

The memory <NUM> may be for example a non-volatile or a volatile memory, such as a read-only memory (ROM), a programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), a random-access memory (RAM), a flash memory, a data disk, an optical storage, a magnetic storage, a smart card, or the like. The apparatus <NUM> may comprise a plurality of memories. The memory <NUM> may be constructed as a part of the apparatus <NUM> or it may be inserted into a slot, port, or the like of the apparatus <NUM> by a user.

The communication interface <NUM> may comprise communication modules that implement data transmission to and from the apparatus <NUM>. The communication modules may comprise, e.g., a wireless or a wired interface module. The wireless interface may comprise such as a WLAN, Bluetooth, infrared (IR), radio frequency identification (RF ID), GSM/GPRS, CDMA, WCDMA, or LTE (Long Term Evolution) radio module. The wired interface may comprise such as Ethernet or universal serial bus (USB), for example. Further the apparatus <NUM> may comprise a user interface (not shown) for providing interaction with a user of the apparatus. The user interface may comprise a display and a keyboard, for example. The user interaction may be implemented through the communication interface <NUM>, too.

The database <NUM> may be certain memory area in the memory <NUM> or alternatively the database <NUM> may be a separate component or the database <NUM> may be located in a physically separate database server that is accessed for example through the communication unit <NUM>. The database unit <NUM> may be a relational (SQL) or a non-relational (NoSQL) database.

A skilled person appreciates that in addition to the elements shown in <FIG>, the apparatus <NUM> may comprise other elements, such as microphones, displays, as well as additional circuitry such as memory chips, application-specific integrated circuits (ASIC), other processing circuitry for specific purposes and the like. Further, it is noted that only one apparatus is shown in <FIG>, but the embodiments of the invention may equally be implemented in a cluster of shown apparatuses.

Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is ability to automate network monitoring and control in telecommunication networks.

Another technical effect of one or more of the example embodiments disclosed herein is that increasing number of issues in monitored devices can be solved before they are visible to end users thereby improving user experience. Another technical effect of one or more of the example embodiments disclosed herein is that complex systems with increasing traffic amount can be handled without necessarily needing additional personnel for network monitoring tasks.

Another technical effect of one or more of the example embodiments disclosed herein is that risk of human errors may be reduced. For example in a NOC functionality it is likely that due to huge amount of alerts to be monitored, some alerts may go unnoticed by the monitoring personnel. Whereas, in the automated solution, all alerts are equally processed.

Claim 1:
A computer implemented method of network monitoring and control, the method comprising
identifying (<NUM>) an alert related to a monitored device of a group of monitored devices (<NUM>);
confirming (<NUM>) that automatic actions are applicable for the monitored device, by checking that a ticket associated with the monitored device does not exist and that automatic actions do not interfere with ongoing actions being performed in the monitored device, wherein the ticket is a ticket for manual action enabling human intervention if needed, the ticket indicating that a problem associated with the monitored device has already been identified; and
performing (<NUM>) at least one predefined automatic action for the monitored device, the action being selected based on the identified alert.