METHODS OF IMPLEMENTING A DYNAMIC SERVICE-EVENT MANAGEMENT SYSTEM

• US 20150127988A1
• Filed: 12/19/2014
• Published: 05/07/2015
• Est. Priority Date: 06/25/2012
• Status: Active Grant

• Current Assignee: KNI Muszaki Tanacsado KFT
• Original Assignee: KNI Muszaki Tanacsado KFT
• Inventors: Kendi, Zsolt, Paroczai, Istvan
• Granted Patent: US 9,436,541 B2
• Time in Patent Office: Days
• US Class Current: 714/37
• CPC Class Codes: G06F 11/0709 in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
• CPC Class Codes: G06F 11/079 Root cause analysis, i.e. error or fault diagnosis in a hardware test environment G06F11/22; in a software test environment G06F11/36
• CPC Class Codes: H04L 41/065 involving logical or physical relationship, e.g. grouping and hierarchies
• CPC Class Codes: H04L 43/091 Measuring contribution of individual network components to actual service level

Abstract

Dynamic service-event management methods to implement a dynamic service-event management system. Generally applicable in fields of utility, telecommunication and financial service providers. Therein, events has affect to status or quality of service projecting to service in two steps and using common-format events. In first step, external source originated events (11, 21, 24) are converted in network parser module(s) (1, 2) to a common event-format. In second step, the common format events (12, 22) are processed and their information projected to a service in a service parser module (3). The resulting common format service-event (31) and network events (13, 23) are stored by an alert parser module (4). The stored events are accessible for other connected systems through a database based application programming interface (41). Opening times are effectively handled using opening events (61). A bearer-to-beared object assignment can be handled in two ways. In the easiest solution information originated from an event source is used. Another possible solution uses a static database which is maintained by a database parser module (5). The static database is accessible for other connected systems through a database based application programming interface (51).

Claims

1. A method of implementing a dynamic service-event management system, comprising the steps of

describing assigned service by describing the position of an event source within bearers of the service as a two-dimensional route description, wherein a route constitutes the first dimension and an element within the route constitutes the second dimension, or as a three-dimensional route description, wherein a route constitutes the first dimension, an element within the route constitutes the second dimension and the bearer of the element within the route constitutes the third dimension;

projecting of one or more events affecting status and/or quality of a service onto said service in two steps by using a common-format event type,

in the first step, converting an event (11, 21, 24) originating from an external source in a network parser module (1, 2) to a common-format event including

an identifier of the source of the incoming event (11, 21, 24) as an event source identifier,

a status generated by the incoming event information as a status,

an operational status generated by an incoming event information expressed in percentage,

an identifier of the incoming event source as a failure cause expressed in common-format,

in the second step, by processing the resulting common-format event (12, 22) in a service parser module (3), where the common-format event comprising

the event source identifier,

the status carried by the event,

the number defining the operational status expressed in percentage,

the failure causes expressed in common-format;

obtaining assigned service and the position of the event source within the bearers of the service from the event source identifier with the aid of the two-dimensional or three-dimensional route description between bearers of the service;

projecting the information carried by the common-format event (12, 22) onto said service by determining a number of operational routes based on the received common-format event (12, 22) and stored status of the bearers of the service, then based on the above;

deciding the status of service is operational if there is an operational route, else deciding the status of service is faulty;

determining the operational status of the service expressed as a numerical ratio of operational routes and faulty routes in percentage;

determining that the failure cause of the service are the failure causes of faulty routes;

storing the common-format event (12, 22) comprising actual status of bearer in a memorabilia.

2. The method of claim 1 further comprising the step of performing of a function “

failure cause of the failure cause”

by using a common-format event in such a way that, if the event source being not the failure cause per se just affected by it, then indicating a real failure cause object and the event source in a multi element failure cause variable of the common-format event and obtaining relationships between the network objects from the event source identifier.

3. The method of claim 1, further comprising the step of persistently storing of common-format events (13, 31, 23) for e.g. retrieval or processing.

4. The method of claim 1, further comprising the step of making the data of persistently stored common-format events and the static database comprising assign-to-service and assign-to-network information accessible for other connected systems via a database based application programming interface (API) (41, 51) wherein said bidirectional interface is represented by a command database table and a response database table, and further comprising

for issuing a command, entering one line in the command database and transmitting the command,

monitoring, receiving, interpreting and executing the command,

sending a response through said response database table,

wherein formats of command and response are defined by the respective database table.

5. The method of claim 1, wherein

the step of obtaining the assigned service, then the position of the event source within the bearers of the service based on the event source identifier by assignment-retrieval with the aid of a static database comprising all alert-objects affecting the service and defining the interrelations in a table with the aid of two-dimensional or three-dimensional referencing between bearers of service.

6. The method of claim 5, further comprising the steps of handling of predefined opening hours by an opening calendar, creating a common opening calendar for alert-objects having same opening hours, monitoring the calendar and at opening hour changes sending a related opening event to related parser modules and effectuating the changes to related alert-objects.

7. The method of claim 5, further comprising the step of performing of a function “

failure cause of the failure cause”

by using a common-format event in such a way that, if the event source being not the failure cause per se just affected by it, then indicating a real failure cause object and the event source in a multi element failure cause variable of the common-format event and obtaining relationships between the network objects from a static database containing all alert-objects affecting each other.

8. The method of claim 5, further comprising the step of persistently storing of common-format events (13, 31, 23) for e.g. retrieval or processing.

9. The method of claim 5, further comprising the step of making the data of persistently stored common-format events and the static database comprising assign-to-service and assign-to-network information accessible for other connected systems via a database based application programming interface (API) (41, 51) wherein said bidirectional interface is represented by a command database table and a response database table, and further comprising

for issuing a command, entering one line in the command database and transmitting the command,

monitoring, receiving, interpreting and executing the command,

sending a response through said response database table,

wherein formats of command and response are defined by the respective database table.