Telephonic communications – With usage measurement – Call traffic recording by computer or control processor
Reexamination Certificate
2000-06-09
2003-09-23
Kuntz, Curtis (Department: 2643)
Telephonic communications
With usage measurement
Call traffic recording by computer or control processor
C379S133000, C379S134000, C379S137000
Reexamination Certificate
active
06625266
ABSTRACT:
FIELD OF THE INVENTION
This invention generally concerns a method for reading and preprocessing a huge quantity of individual elementary events which are to be monitored in such a way that only desired events or sets of events are extracted for further processing.
TECHNICAL BACKGROUND
There are applications in numerous telecommunication facilities where huge quantities of data are collected. Numerous counters, measuring events producing measurement results and events to be monitored are used in the collection. Counters are typically used to measure the duration of an event. Sometimes the duration is without significance, so that only such information is sufficient which tells whether an event has occurred or not. An example of such is some magnitude which must be monitored, such as temperature, voltage, current, number of events or any other such threshold value the exceeding or falling short of which is an event to be monitored. In some cases again information on the present value of the magnitude to be measured is needed at the moment of inquiry. In many cases, the readings of counters, events and measurements are dependent on one another, but this is by no means always the case.
Hereinafter, the name elementary event will be used for the sake of brevity to mean both a counter operation, a measurement and any individual event.
The telephone exchange is a typical telecommunication facility which produces an enormous quantity of data. It may contain even thousands of counters, some of which are working all the time, while some work at times, e.g. for periods of 15 minutes, and some will work when triggered off by a threshold value. In addition, it includes many events which must be monitored and the implementation of which will start some function. All these elementary events represent an enormous data flow which is constantly changing. From this information flow the operator selects the data he needs for further processing. The operator tells the manufacturer of the exchange what information he needs and in what form it should be. The manufacturer then makes such arrangements in the software of the exchange which will filter out the desired events from the elementary events and will locate them in so-called reports, which are used in the exchange or which are sent out from the exchange e.g. to network management. Typical reports are the accounting data needed to carry out charging, various statistical reports, reports needed in traffic control etc.
A CDR report is presented as an example of a report. For each call which is made the Local Exchange LE performs call detailed charging and forms a Call Detail Recording CDR. The record contains for one call all the data needed to charge for the call as well as the desired quantity of other data relating to the call. Such data is e.g. the A number, the B number, the duration of the call and the moment when the call begins and ends respectively. The formed CDRs are sent to billing centre BC for further processing. In order to generate the call detail recording, the operator must establish some basis to form it. The ground for formation may be e.g. call detailed data collection for all calls of the subscriber or a formation based on the type of call, that is, whether the call is an ordinary call, a facility call such as call forwarding, a call free of charge etc. The call detailed data collection thus produces enormously big data blocks which contain even millions of records and which must be stored in the mass memory of the charging system. The counters, besides forming the charging record, also find out whether the call was successful or not, and the result is used for statistical purposes. For traffic management such reports are produced which show the number of successful and failed calls as a function of time.
FIG. 1
illustrates the practice mentioned above. The elementary events arriving from various sources are combined in the counting process to form raw data blocks, which are then moved on to charging, statistics-keeping etc. for further processing. The processor may need only a fraction of information from the raw data block, but in spite of this, all elementary events must be read and the processor must receive the whole data block.
It is a problem with the present arrangements that in a telecommunication facility, such as a telephone exchange, the quantity of arriving data is so big that the statistic, traffic management and charging systems do not have the time for processing the information, at least not in real time, so their processing capacity has become a bottleneck. This may be harmful both to the operator and to the customer. As an example such a situation may be mentioned where some such necessary piece of charging data is lacking in the subscriber's call set-up which the traffic management has not had the time to produce due to the data overflow constantly arriving there. When this necessary piece of data is missing, the call can not be connected at all.
It is an objective of this invention to eliminate the problems occurring in the present-day arrangements.
The objective is achieved with the system defined in the independent claims.
BRIEF SUMMARY OF THE INVENTION
The system according to the invention includes two main blocks: the first main block is comprised of one or more report request service blocks and the second main block is comprised of one or more counter service blocks, wherein each counter service block monitors one or more elementary events, such as a counter. The system at a minimum includes at least one report request service block and one counter service block.
The task of each report request service block is to form a report. It may receive a request from outside of the system, or some factor inside the system may trigger off a request. From the request it concludes what information on what elementary events is needed in the report. Thereafter information on the required elementary event is relayed as a start-up request to those counter service blocks, which are monitoring the said elementary events. In response to the request, these counter service blocks state the values of the said elementary events to the report request service block, which will use the received data for forming a report.
The elementary events, that is, counters, meters and events, work in the ordinary way producing information as a constant flow. The elementary events can be grouped in such a way that one counter service block may monitor several elementary events. Each counter service block reads the values of the connected elementary events in accordance with a predetermined instruction. Thus, the counter service block is a kind of controller.
The predetermined instruction is given by the report request service block. In the instruction those conditions are given on which the value of each elementary event is desired. The condition may be exceeding/falling short of a given threshold value or the condition may be a timetable, e.g. a time slot, by which the value of the elementary event must be stated. When the given condition is fulfilled, the requested counter service blocks will read the elementary event information and will locate it in a brief message, each piece of information in its own message, and will send the message to the report request service block.
Thus, the essential idea of the invention is to send on from the places of observation of elementary events that information only which is needed at each time and only when it is needed. All other such information on elementary events which is not needed at the time in question is not sent. The flow of information can thus be reduced considerably and the capacity of upper levels is prevented from becoming a bottleneck.
The first embodiment is a static embodiment of the basic inventive idea. According to this, each counter service block and the related elementary events form a predetermined permanent entity. The report request service block sends a request to those counter service blocks only on the monitored elementary events of which it needs information. T
Saari Jarmo
Taskinen Timo
Kuntz Curtis
Nokia Corporation
Taylor Barry W
LandOfFree
Event pre-processing for composing a report does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Event pre-processing for composing a report, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Event pre-processing for composing a report will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3043576