JP2001237988A - Billing information rescue method and device - Google Patents

Abstract

(57) [Summary] The present invention relates to a method and a device for relieving charging information, and an object of the present invention is to be able to collect appropriate charging data even when a system fails. SOLUTION: In a billing information rescue method of a communication system for monitoring a provision time of a communication-related service and generating corresponding billing information based on the provision time, a start time of the communication-related service is set at the start of the communication-related service. Obtaining and storing in a non-volatile storage means, and obtaining a fault occurrence time due to the occurrence of a fault in the communication system in which the service is continuing, and storing the same in the non-volatile storage means, and after the communication system is restored, the storage The corresponding billing information is generated based on the service providing time from the specified start time to the failure occurrence time.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method and an apparatus for relieving billing information, and more particularly to a service time of a communication-related service (a telephone service of an exchange, a data communication service, a connection service of an Internet service provider, etc.). The present invention relates to a charging information rescue method of a communication system and a device therefor, which monitors the communication time and generates corresponding charging information based on the provided time.

[0002] Today, the Internet is widely used not only by specific educational institutions such as universities, but also by general end users because of its diversity and versatility. The telephone line that serves as the communication medium plays a new role of transmitting and receiving data, in addition to the role of simply talking between someone as before, which is a comparison of two hours or three hours. This leads to the fact that long calls occur both day and night. In addition, the social approach to networking is still in the process of development, and this tendency can be said to become even stronger in the future. Therefore, it is considered that the profit of a relatively long-term call such as data communication will increase in the future for carriers (operators), and therefore, it is required to reliably collect and store detailed billing data.

[0003]

2. Description of the Related Art FIG. 9 is a diagram for explaining the prior art, showing a process of collecting detailed billing information in an exchange. Conventionally, a storage area for detailed billing data is provided on an auxiliary storage device (such as a hard disk) of the apparatus, and a call start (answer) time and a call end time are collected and stored for each call. On the other hand, the billing and settlement cannot be carried out frequently because the amount of processing is enormous, and usually the start time of the call is determined by using the simplest time zone (for example, around 4 am) with the least traffic volume. The so-called regular fee settlement was performed on the basis of and the closing time.

[0004]

However, as shown in the figure, there is a case where a call A, B, or C during a call encounters a system failure during the call. With the method of generating billing data based on the billing method, billing processing cannot be performed normally for calls A, B, and C that do not end the call, and as a result, billing cannot be performed. This applies not only to the charging system for the exchange, but also to a charging system for an Internet service provider connection service.

SUMMARY OF THE INVENTION The present invention has been made in view of the above-mentioned problems of the prior art, and an object of the present invention is to provide a charging information rescue method and apparatus capable of collecting appropriate charging data even in the event of a system failure. It is in.

[0006]

The above-mentioned problem is solved, for example, by referring to FIG.
The problem is solved by the configuration of (A). That is, according to the billing information rescue method of the present invention (1), in a billing information rescue method of a communication system that monitors a provision time of a communication-related service and generates corresponding billing information based on the provision time, At the start of the related service, the start time is obtained and stored in the non-volatile storage means, and the fault occurrence time is obtained by the occurrence of a fault in the communication system in which the service is continued, and the non-volatile storage means is obtained. It is for storing and generating corresponding charging information based on the service providing time from the stored start time to the fault occurrence time after the communication system is restored.

According to the first aspect of the present invention, a failure occurrence time is acquired when a failure occurs in a communication system in which service is continued, and the failure occurrence time is stored in a nonvolatile storage means.
It is possible to properly charge at least from the start of the service to the occurrence of a failure.

The above-mentioned problem is solved, for example, by the structure shown in FIG. That is, according to the billing information rescue method of the present invention (2), in the billing information rescue method of the communication system for monitoring the providing time of the service related to the communication and generating the corresponding billing information based on the providing time, A predetermined time interval is periodically cumulatively added from the start time of a related service, and the cumulative addition result is stored in a non-volatile storage unit each time. After the system is restored, corresponding charging information is generated based on the stored information of the latest cumulative addition result.

According to the present invention (2), a predetermined time interval is periodically added from the start of the service related to communication, and the cumulative addition result is stored in the non-volatile storage means each time. With this configuration, even if a system failure occurs, it is possible to properly charge at least from the start of service to immediately before the occurrence of the failure. In addition, the configuration is such that the cumulative addition result is stored in advance in the non-volatile storage means each time.
For example, billing data can be reliably generated even when a serious failure occurs in which the failure time cannot be recorded in the nonvolatile storage means.

The switching system of the present invention (3) accommodates a plurality of subscriber terminals, controls call exchange between these terminals and the network, monitors the duration of the call, and monitors the duration of the call. An exchange device for generating corresponding charging information based on the
At the start of the call to be charged, the start time is obtained and stored in a non-volatile storage means, and the fault occurrence time is obtained when a fault occurs in the device during the call and the non-volatile storage means is obtained. And a billing information rescue means for generating billing information of the call to be rescued based on the stored call duration from the start time to the failure occurrence time after the device is restored. .

[0011] Preferably, in the present invention (4), in the above-mentioned present invention (3), the call duration monitoring means stores a failure occurrence time of the device in a common storage area, and sets a call start time and the common start time. The pointer information indicating the storage area is stored in the storage area for each call, and the charging information rescue means stores the charging information for each call based on the stored start time for each call and the fault occurrence time referenced by the pointer information. Generate

According to the present invention (4), the fault occurrence time of the device is stored in a single common storage area, so that the fault occurrence time only needs to be written once in a specific storage area. There is a high possibility that the fault occurrence time can be recorded even under a fault condition.

Further, the switching equipment of the present invention (5) accommodates a plurality of subscriber terminals, controls call exchange between these terminals and the network, monitors the duration of the call, and monitors the duration of the call. An exchange device for generating corresponding charging information based on the
A call duration monitoring means for periodically accumulating predetermined time intervals from the start of the call to be charged and storing the cumulative addition result in a non-volatile storage means each time; With this configuration, there is provided a billing information rescue means for generating the billing information of the call to be rescued based on the stored information of the latest cumulative addition result after the device is restored.

[0014]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of the present invention will be described below in detail with reference to the accompanying drawings. Note that the same reference numerals indicate the same or corresponding parts throughout the drawings.

FIG. 2 is a block diagram of an exchange according to the embodiment. In the figure, reference numerals ₁₁ to 1 _{n denote} subscriber terminals (telephones, data terminals, PBXs, etc.), 10 denotes a central office exchange, and 11 _{1 to} 11 _n.
Is a line circuit for accommodating subscriber terminals, 12 is a network circuit unit (NW) including a speech path switch and the like, and 13 ₁ to 1
3 _m is a central office trunk connected to the network side, 14 is various service trunks, 15 is a CPU for performing main control and processing (normal call processing, charging information rescue processing described later, etc.) of the exchange, 16
Is a main memory (MEM) composed of a ROM, a RAM and the like used by the CPU 15, 17 is an auxiliary storage device composed of a hard disk or the like, 18 is a communication interface (CIF), 30
Is a maintenance console.

Reference numeral 50 denotes various functional blocks realized by the execution of the program by the CPU 15. 51
Is a normal call process for exchanging calls (connection, disconnection, management, etc.), 52 is a remedy target condition setting process for setting call conditions for rescue billing information, and 53 is obtained at the start (answer) of a call. Register (record) detailed billing information to be recorded on the disk 17
Detailed billing information registration processing, 54 is a failure time recording processing for recording a failure time on the disk 17, 55 is a call time update processing for cumulatively adding a predetermined time interval from the start of the call and overwriting and recording on the disk 17, 56 Is a call end time recording process for recording the call end time on the disk 17, 57 is a charge information rescue process for relieving the charge information of a failed call in accordance with a collection mode, 58 is a system restart process after a failure has occurred, and 59 is a regular period. Routine work (for example,-
1 is a periodic process for executing the process, and 60 is a detailed billing information output process for outputting detailed billing information of the disk 17 to the maintenance console 30 or the like.

FIG. 3 is an explanatory diagram of storage information in the main memory (RAM) 16 and shows storage areas of various types of information relating to detailed billing information rescue processing described later. In the drawing, reference numeral 31 denotes a call processing work area for generating, managing, and releasing each call, and storing detailed management operation information for the call; and 32, a call information rescue method (collection type) for each call. A rescue target call management area 33 to be stored is a counter area for counting a predetermined time interval from the start of the call for each call, and these are call numbers 1 to n.
Are commonly referred to by Further, reference numeral 35 denotes a search table for determining whether or not the newly generated call is a remedy target call of the billing information.

The maintenance person can set the contents of the search table 35 from the maintenance console 30 in advance. In the column of "conditions for specifying call to be rescued", the call type (call call, data call, etc.), subscriber type (primary, secondary, etc.) and trunk (I
SUP outgoing line connection numbers 13 ₁ , 13 _3, etc.), and the counter setting value (3, 2
Etc.) and rescue method of billing information (collection type =, etc.)
Set each information. The counter setting value can be set to an arbitrary time interval for each call. Therefore, the time interval can be shortened for a certain call so that accurate billing information can be obtained, and for other calls, the time interval can be set. Can be lengthened to reduce the burden of the cumulative addition process. In addition, the maintenance person determines a plurality of conditions (1) by combining these parameters.
To (k) can be arbitrarily set, so that flexible charging information rescue control for calls under various conditions can be easily performed.

FIG. 4 is an explanatory diagram of storage information of the auxiliary storage device (disk) 17 and shows storage areas of various types of information relating to a billing information rescue process described later. In the figure, reference numeral 41 denotes a fault time storage area for storing a fault occurrence time; 42, a detailed charging information storage area for storing detailed charging information; and 43, a pointer table for converting a call number into a detailed charging information storage area for each call. It is.

The failure time information is written each time a failure occurs, and the address is updated each time. Since it is conceivable that a plurality of failures may occur between the transmission of the detailed billing information to the billing center and the next transmission thereof, several times can be stored. Note that the failure time has not yet been written in the latest storage area (address m) in the figure, and the next time a failure occurs, the failure occurrence time is quickly written. Hereinafter, detailed billing information rescue processing using these pieces of information will be described in detail.

FIGS. 5 to 8 are flowcharts (1) to (4) of the detailed billing information rescue process according to the embodiment. FIG. 5 shows a detailed billing information registration process. When a call to be charged (such as a response to an outgoing call) occurs, an input is made to this process. Various kinds of information necessary for call management such as the call start time of the call and obtained up to the present time are stored in the call processing work area 31 by the call processing unit 51 in advance.
In step S1, the search table 35 is referred to using necessary call information in the call processing work area 31, and a collection type and a counter set value are acquired for a call that meets the conditions. In step S2, the counter setting value is set in the counter (I) referred to by the call number I in the counter area 33. In step S3, the collection type is set to the collection type (I) referenced by the call number I in the rescue target call management area 32. In step S4, a pointer (I) in the detailed charging information storage area 42 corresponding to the call number I is added to the pointer table 43. In step S5, the detailed billing information is recorded at the address referred to by the pointer (I) in the detailed billing information storage area 42. In step S6, the latest failure time storage address (currently m) is recorded in the failure time identification flag. FIG. 4 shows an example of detailed billing information. At this time, the information of the talk time and the end time of the call is undecided.

FIG. 6 shows a talk time update process.
When a timer interrupt occurs at a predetermined time interval T, the processing is input. In step S11, the call number = 1 is set in the call number index register I. In step S12, the content of the counter (I) referred to by the call number (I) is "F
F ”(all bits“ 1 ”). If the counter (I) = “FF”, the flow is out of the target of the charging rescue service by the counter, and the process proceeds to step S17. In step S17, +1 is added to the register I. Step S18
Then, it is determined whether or not I> n (n: last call number). I
If not> n, the process returns to step S12 to check the next counter.

If it is determined in step S12 that the counter (I) 判別 “FF”, the content of the counter (I) is decremented by one in step S13. In step S14, it is determined whether or not the counter (I) = 0. If the counter (I) ≠ 0, the flow advances to step S17 to check the next counter in the same manner as described above.

If the counter (I) = 0 in the determination in step S14, the counter set value (I) referred to by the call number (I) in the call processing work area 31 is stored in the counter (I) in step S15. set. In step S16, a predetermined call time interval {= counter set value (I) × T} corresponding to the call number I is accumulated in the call time (I) referred to by the call number (I) in the detailed charging information storage area 42. Add and overwrite. In step S17, the next counter is checked in the same manner as described above. Thus, step S18
If I> n in this determination, the processing exits.

In this example, the counter service is performed irrespective of the collection type, but this is designed so that even if a failure of the collection type cannot be obtained, a failure can be obtained by the collection type. But not limited to this. That is, the counter service may be provided only when the collection type is.

FIG. 7A shows a failure time recording process. When a failure that causes the system to go down occurs in the operating system, this process is inputted. Step S2
In step 1, the failure occurrence time is recorded in the latest storage area (address m) of the failure time storage area 41, and the process exits. Preferably, when a failure occurs, this processing is performed with the highest priority, so that the failure occurrence time is secured.

FIG. 7B shows the charging information rescue process, which is input to this process at an appropriate timing after the system is restarted. In step S31, the call number = 1 is set in the call number index register I. In step S32, the information (collection type) referred to by the call number (I) in the detailed charging information storage area 42 is checked. In step S33, processing branches according to the collection type. If collection type =
In step S34, the failure occurrence time referred to by the failure time identification flag (I) is recorded in the end time (I) column. That is, a failure is encountered during a call, and the call termination time of a call that cannot be normally terminated is substituted with the failure occurrence time. If the collection type =, the contents of the call start time (I) + the talk time (I) are recorded in the column of the end time (I) in step S35. That is, the end time of the failure encounter call is substituted by the failure occurrence time by the counter service. Furthermore, if the collection type = (not to be remedied), step S3 remains
Proceed to 6. In step S36, +1 is added to the register I, and in step S37, it is determined whether or not I> n. If I> n is not satisfied, the process returns to step S33 to recover the next detailed billing information. Then, when I> n, the processing exits.

FIG. 8A shows a call termination time recording process. When a call during a call is normally terminated, an input is made to this process. In step S41, the current time (end time) is recorded in the end time (I) column of the end call, and the process exits.

FIG. 8B shows the detailed billing information output process. For example, when there is a command to output the detailed billing information from the maintenance console 30, the process is input to this process. Step S51
Then, the output section information (for example, 1999/11/23 /
07:10 to 1999/11/23/17: 50). In step S52, the detailed charging information storage area 42
To collect detailed billing information for the specified section. In step S53, the extracted detailed billing information is
To be displayed. In step S54, detailed billing information is transmitted to the billing center if necessary. Incidentally, the charging center obtains the call time from the start time of the call minus the end time of the call. Whether or not this is a normal call time can be recognized by referring to the collection type. In addition, if the collection type =, but the end time of the call (that is, the failure occurrence time) is not recorded, it is possible to use the start time and the call time to recover the charge.

In the above embodiment, an example of application to the exchange service has been described. However, the present invention provides a charging remedy based on the time of providing various other services such as a connection service of an Internet provider and an information providing service of various servers. Applicable to

Although the preferred embodiments of the present invention have been described, the configuration of each part,
It goes without saying that various changes in control, processing and combinations thereof can be made.

[0032]

As described above, according to the present invention, it is possible to collect appropriate billing data even in the event of a system failure, and it is possible to effectively reduce the loss of long-term call profit.

[Brief description of the drawings]

FIG. 1 is a diagram illustrating the principle of the present invention.

FIG. 2 is a block diagram of an exchange according to the embodiment.

FIG. 3 is an explanatory diagram of information stored in a main memory (RAM) 16;

FIG. 4 is an explanatory diagram of storage information of an auxiliary storage device (disk) 17;

FIG. 5 is a flowchart (1) of detailed billing information rescue processing according to the embodiment;

FIG. 6 is a flowchart (2) of a detailed billing information rescue process according to the embodiment;

FIG. 7 is a flowchart (3) of detailed billing information rescue processing according to the embodiment;

FIG. 8 is a flowchart (4) of detailed billing information rescue processing according to the embodiment;

FIG. 9 is a diagram illustrating a conventional technique.

[Explanation of symbols]

1 ₁ to 1 _n subscriber terminal 10 central office exchange 11 _{1 to} 11 _n line circuit 12 network circuit section (NW) 13 _{1 to} 13 _m office line trunk 14 service trunk 15 CPU 16 main memory (MEM) 17 auxiliary storage device 18 communication Interface (CIF) 30 Maintenance console

Claims (5)

[Claims] 1. A charging information rescuing method for a communication system for monitoring the provision time of a communication-related service and generating corresponding charging information based on the provision time. And stores it in a nonvolatile storage means, and obtains a failure occurrence time due to the occurrence of a failure in the communication system in which the service is continuing and stores the failure occurrence time in the nonvolatile storage means. A charging information rescue method, wherein corresponding charging information is generated based on a stored service providing time from a start time to a failure occurrence time. 2. A charging information rescue method for a communication system for monitoring a provision time of a communication-related service and generating a corresponding charging information based on the provision time. The cumulative addition result is stored in a non-volatile storage means each time, and a failure occurs in the communication system in which the service is continued. And generating corresponding charging information based on the information of the cumulative addition result of the charging information. 3. An exchange for accommodating a plurality of subscriber terminals, performing call switching control between them and a network, monitoring the duration of the call, and generating corresponding charging information based on the duration. The device obtains the start time at the start of the call to be charged and stores the start time in a non-volatile storage unit, and obtains the fault occurrence time when a fault occurs in the device during the call continuation, and obtains the non-volatile time. Call duration monitoring means stored in the storage means, and charging information rescue means for generating, after restoration of the apparatus, the charging information of the rescue target call based on the stored call duration from the stored start time to the failure occurrence time. An exchange device characterized by the above-mentioned. 4. The call duration monitoring means stores a fault occurrence time of the apparatus in a common storage area, and stores a call start time and pointer information indicating the common storage area in a storage area for each call. 4. The switching apparatus according to claim 3, wherein the charging information rescue means generates the charging information for each call based on the stored start time for each call and the failure occurrence time referred to by the pointer information. . 5. An exchange for accommodating a plurality of subscriber terminals, performing call switching control between them and a network, monitoring the duration of a call, and generating corresponding charging information based on the duration. A call duration monitoring means for periodically accumulating a predetermined time interval from the start of the call to be charged and storing the cumulative addition result in a non-volatile storage means each time; An exchange unit comprising: charging information rescue means for generating charging information of a call to be remedied based on the stored information of the latest cumulative addition result after recovery of the apparatus when a failure has occurred.