KR100400351B1 - A METHOD FOR TRANSMITTING CDR(Call Detail Report) PACKET BETWEEN GATEWAY AND CDR SERVER - Google Patents

Abstract

The charging packet transmission method between the gateway and the charging server of the present invention can be read by a computer recording a method for preventing the loss of the charging packet when the charging server is down when the VoIP gateway does not have a file system or a disk device, and a program for realizing the charging packet. Provide a recording medium. To this end, the present invention provides a charging packet transmission method between a charging server and at least one gateway that does not have a file system or a disk device in a communication system including one or more charging servers. A first step of notifying a local operations management server of downtime of a charging server; and if the amount of charging packets generated after all of the charging servers are down exceeds the threshold of allocated memory, operating the exceeded charging packets in the local operation. A second step of storing in the management server and transmitting the charging packet stored in the memory and the charging packet stored in the local operation management server to the restored charging server when at least one of the down charging server is restored. Includes three steps.

Description

Method of transmitting charging packet between gateway and charging server {A METHOD FOR TRANSMITTING CDR (Call Detail Report) PACKET BETWEEN GATEWAY AND CDR SERVER}

The present invention relates to a charging packet transmission method between a gateway and a charging server. More particularly, the present invention relates to VoIP, which provides a voice communication service based on an internet network in real time and in both directions through a telephone or a PC by connecting a telephone network and an internet network. The present invention relates to a method of transmitting a charging packet between a gateway and a charging server to prevent the loss of the charging packet when the charging server is down when the gateway does not have a file system or a disk device, and to a computer-readable recording medium recording a program for realizing the charging packet. .

In general, the exchange performs call-related tasks such as number translation, voice resource allocation, and additional service processing so that telephone users can use the telephone, generates charges related to the processed calls, and temporarily stores them in the charge memory queue. When a certain amount of billing is collected, it is stored on the billing hard disk or billing magnetic tape. The generated charge is sent to the settlement.

In the conventional exchanger, if the charge storage medium fails or the charge transfer software fails, charge loss occurs and online charge transfer and settlement are impossible. That is, conventionally, when charging occurs in the exchange, it is temporarily stored in the charging memory queue, and when a certain amount is stored in the charging hard disk. In this case, if the charging hard disk or the charging magnetic tape (MT) fails and cannot be stored, the charges accumulate in the charge memory queue. If a predetermined time elapses in this state, the charge on the charge memory queue is discarded. This occurred, causing the loss of billing.

As an example for overcoming such a problem, when the billing function has a failure in the Korean Patent Application No. 1999-01955, a communication processing system for online transmission of lost charges accumulated in the storage means after the failure occurs to the billing settlement center. There is disclosed a method for preventing loss due to an obstacle in Esau. When the charging function accumulates in the charging memory queue in the communication system, the method notifies to the external charging storage medium (billing settlement center) and to settle the on-line charging to the charging settlement center accumulated in the charging memory queue. It is possible to automate the billing settlement online even in the event of a billing failure of the exchange by preventing the billing loss due to the billing malfunction.

However, the above method of preventing the lost charge stores the lost charge in the file system or disk when charging failure occurs in the exchange, and transmits the stored charge to the charging server when the charging function is restored. In particular, the VoIP gateway shuts down the charging server. If there is no file system or disk device storing lost charges, there is a problem that the lost charges cannot be stored.

As such, the conventional communication system stores charging information in its own file system or disk when the charging server is down, and transmits the charging information stored in the file system or disk to the charging server when the charging server is restored after a predetermined time. Was drunk. However, in order to have an excellent price competitiveness, when the VoIP gateway does not have a file system or a disk device, there is a problem in that it cannot be stored in its own file system or disk when the billing server is down.

The present invention has been made to solve the above problems, when the VoIP gateway does not have its own file system or disk device when the billing server is down when the VoIP gateway informs the local operations management server and when the billing information is generated If the threshold is exceeded and the threshold is exceeded, the accounting information stored in the memory is stored in the file of the local management server in the form of file. It is an object of the present invention to provide a billing packet transmission method for preventing the loss of billing information by providing a transmission method to a billing server, and a computer-readable recording medium recording a program for realizing the billing information.

1 is a block diagram showing an embodiment of the interworking between the gateway and the billing server according to the present invention.

2 is an embodiment of a functional block diagram of a gateway according to the present invention.

3 is a functional block diagram illustrating an embodiment of a charging packet transmission function of a gateway according to the present invention.

4 illustrates an embodiment of a memory structure for storing a charging packet according to the present invention.

Figure 5 shows one embodiment of the processing process during the down and recovery of the billing server according to the present invention.

6 is a flowchart illustrating a charging packet transmission process from a gateway to a charging server according to the present invention.

7 is a flowchart illustrating a charging packet processing process when the charging server is down according to the present invention.

8 is a flowchart showing a charging packet processing process when recovering a charging server according to the present invention.

Explanation of symbols on the main parts of the drawings

11: gateway 13: gatekeeper

16,17: billing server 21: telephone network matching unit

22: signal processor 23: voice processor

24: real-time fax processor 25: Internet matching unit

26: management unit 41: billing information table

42: charging packet 43: flag

44: charging packet header 45: pointer

46: attribute 54: regional operations management server

According to an aspect of the present invention, there is provided a charging packet transmission method between at least one gateway having no file system or a disk device and a charging server in a communication system including at least one charging server.

Informing a local operations management server of the downtime of the charging server when all of the one or more charging servers are down;

A second step of storing the exceeded charging packet in the local operation management server when the amount of the charging packet generated after all the charging servers are down exceeds the threshold of the allocated memory; And

And when a charging server of at least one of the down billing servers is restored, transmitting a charging packet stored in the memory and a charging packet stored in the local operation management server to the restored charging server.

In addition, the present invention for achieving the above object is a communication system having a processor to manage a redundant billing server,

A first function of notifying the local operation management server of the downtime of the first billing server and transmitting a billing packet generated after the first billing server having a high priority to the second billing server having a lower priority;

If the second billing server is down after the first step, the local management server is notified of the downtime of the second billing server, and if the amount of billing packets generated after the threshold exceeds the allocated memory threshold A second function of storing to the server; And

A computer-readable recording recording a program for executing a third function of transmitting the charging packet stored in the memory and the charging packet stored in the local operation management server to the restored charging server when at least one charging server is restored. Provide the medium.

Hereinafter, the present invention will be described in more detail with reference to the drawings.

1 is a block diagram showing an embodiment of the interworking between the VoIP gateway and the billing server to which the present invention is applied. As shown in FIG. 1, the gateway 11 may be connected to the charging servers 16 and 17 through the gatekeeper 13 and may also be directly connected to the charging servers 16 and 17. At this time, the billing server is duplicated for stabilization and there are two billing servers 16 and 17. However, the redundant billing servers 16 and 17 illustrate one example, and two or more billing servers may be built in order to be more stable. When the charging information is transmitted through the gatekeeper 13, a remote access server (RAS) protocol 12 is used between the gateway 11 and the gatekeeper 13. In addition, when directly transmitting to the billing servers 16 and 17 without the gatekeeper 13, a remote authentication dial-in user service (RADIUS) protocol 15 is established between the gateway 11 and the billing servers 16 and 17. I use it. In the charging packet transmission method of the present invention, a model is described as an interworking structure for transferring charging information between the gateway 11 and the charging servers 16 and 17 using the RADIUS protocol 105.

2 is an embodiment of a functional block diagram of a gateway to which the present invention is applied. As shown in FIG. 2, the VoIP gateway 20 applied to the present invention includes a telephone network matching unit 21, a signal processing unit 22, a voice recognition unit 23, a real-time fax processing unit 24, and an internet matching unit ( 25) and management unit 26 is designed and implemented. The telephone network matching unit 21 is in charge of a telephone network interface, and the signal processing unit 22 is in charge of setting and releasing control of a call, and is in charge of R2 signal processing, SS7 (Signaling System 7) signal processing, and H323 signal processing. . The voice processing unit 23 generates DTMF (dual tone multi frequency) tones and Call Process tones, echo cancel function, voice coding such as G.711, G.723.1, G.729a, and Comfort Noise generation. It is responsible for voice processing functions such as voice processing, real-time transport protocol (RTP) packet conversion function of voice frames, RTP session control function, and the real-time fax processing unit 24 is a fax modem processing function and real-time fax processing. It is responsible for the protocol T.38. The Internet matching unit 25 is in charge of TCP (UDP) / IP function and Ethernet interface for packet transmission, and the management unit 26 is in charge of the management function for the system Simple Network Management Protocol (SNMP; It is in charge of remote management function, interworking with billing server, authentication function, routing table management function, etc.

The VoIP gateway 20 having the above functional blocks performs a H.323 call setup and R2 call setup procedure when a call setup request is received from a telephone network or an internet network, and then sets up a call and sends a call to a billing server. The charging start packet is transmitted, and when the call ends, the charging end packet is transmitted.

3 is a functional block diagram showing an embodiment of a charging packet transmission function of a gateway to which the present invention is applied, and is a block diagram showing a function of transmitting a charging packet to a charging server in a VoIP gateway to which the present invention is applied. As shown in Figure 3, two billing servers are built for stabilization. In the H323 task 32 of the signal processing unit 31, after completing the call processing process, if the call is established by checking the state of the call and the call is connected, the RADIUS task 35 of the management unit 33 provides information necessary for generating a charging packet. To the RADIUS queue 34. The RADIUS task 35 generates a charging packet using the corresponding information and requests the internet matching task 38 of the internet matching unit 36 to transmit the charging packet through the socket interface 37. The Internet matching task 38 transmits the charging packet to the high priority charging server 1 39 when the current charging servers 39 and 30 are all alive, and charges when the charging server 1 39 is down. The charging packet is transmitted to the server 2 (30).

4 illustrates an embodiment of a memory structure of a gateway for storing a charging packet according to the present invention. As shown in Fig. 4, the charging information table 41 is composed of an array of charging packets 42 in series. The charging packet 42 is declared as a structure having a fixed byte value. In addition, the charging packet 42 is composed of a flag 43 (Flag), a charging packet header 44, and a pointer 45 indicating attributes 46 (Attributes), as shown in FIG. Since different attributes exist according to the type of the charging packet 42, the attributes are not included in the charging information table 41 and linked to the pointer 45. The flag 43 indicates whether the memory in which the charging packet 42 is stored is Free or Used, and the charging packet header 44 uses the RADIUS protocol to transmit the charging packet 42. As shown in Table 1, the fixed header used in the RADIUS protocol is used as it is.

TABLE 1

Meanwhile, the RADIUS task 35 shown in FIG. 3 receives the charging information transmitted from the H323 task 32 through the RADIUS queue 34, and then searches the charging information table 41 of FIG. After finding the charging packet, the flag is set to Used and the header and the attribute of the charging packet are generated according to the type of the charging packet. The generated charging packet 42 is transmitted to the internet matching task 38, in which the charging packet does not include a flag. When the RADIUS task 35 receives a response message from the billing servers 39 and 30 through the internet matching task 38, the RADIUS task 35 checks the identifier (ID) value of the reply message and changes the flag of the billing packet to Free. Indicates that this memory can be reused.

FIG. 5 illustrates an embodiment of a processing process during downtime and recovery of a billing server according to the present invention, which is performed by a gateway when one of the redundant billing servers is down and when the billing server is down. Process and the process performed at the gateway when the charging server that was down is restored. Here, the case also applies to more than one gateway. Accordingly, in FIG. 5, the third gateway to n-th gateway are applied to n gateways and represented as gateway n 53. In addition, the gateway has its own memory means but no separate disk device or file system.

As illustrated in FIG. 5, the gateway 1 51 transmits a charging packet to the charging server 1 55 having a high priority when the charging servers 55 and 56 are all alive. Then, if the charging server 1 (55) is down (S501), the gateway 1 (51) notifies the local operation management server 54 that the charging server 1 (55) is down (S502). The regional operation management server 54 notifies each of the other gateways 52 and 53 of down of the charging server 1 55 (S503, S504), and then periodically checks the recovery of the charging server 1 55. (S505). As such, the regional operation management server 54 notifies each of the other gateways 52 and 53 of the charging server 1 55 so that each of the other gateways 52 and 53 receives the charging server 1 55. This reduces the overhead of detecting down.

Subsequently, since the charging server 1 55 having a high priority is down, the gateways 51, 52, and 53 transmit the charging packet to the charging server 2 56 having a low priority (S506).

Then, if the charging server 2 (56) is also down (S507), as in the case of the charging server 1 (55), the gateway 1 (51) detects this to the local operation management server 54 to the charging server 2 (56) (S508) and the local operations management server 54 notifies each of the other gateways (52, 53) (S509, S510). As a result, it is possible to reduce the overhead in which the other gateways 52 and 53 have to sense the down of the charging server 2 56. The regional operation management server 54 checks the recovery of the charging server 2 56 (S511). Since all the billing servers 1, 2 (55, 56) are all down, the gateway 1 (51) sends a billing packet 42 generated after the billing servers 1, 2 (55, 56) are down in its memory. It is stored in the charging information table 41, and it is checked whether the amount of the stored charging packet 42 exceeds the storage threshold of the charging information table 41 (S512). For example, if one charging packet has a set memory of 10, at least 10,000 memories are required to store 1,000 charging packets. In this case, 10,000 is a threshold of the memory.

As a result of the checking in step S512, if the charging packet generated after the down exceeds the memory threshold of the gateway 1 51, the local operation management server 54 stores the charging packet 42 previously stored in the memory. It is transmitted to the store (S513). In this case, the gateway stores the charging packet generated after the down to the threshold value in its memory, and if the charging packet exceeding the threshold is generated later, the gateway cannot store the charging packet that has already been stored. 54) and store it in the regional operation management server 54. The accounting packet generated thereafter is stored again in the emptied memory, and when the threshold value of the memory is reached again, the stored accounting packet is transmitted to the local operation management server 54. Repeat this repeatedly.

When the regional operation management server 54 detects that the down billing server 1 55 has been restored (S514), the gateways 51, 52, and 53 are restored to the billing server 1 55. Inform (S515, S516, S517). As a result, each of the gateways 51, 52, and 53 may reduce the overhead of detecting the recovery of the charging server. When the gateways 51, 52, and 53 know that the billing server 1 55 is restored, the gateways 51, 52, and 53 obtain a billing packet 42 stored in the local operation management server 54 (S518). By transmitting to the server 1 55 (S519), the accounting packet is prevented from being lost even when the accounting servers 55 and 56 are both down. At this time, each of the gateways 51, 52, and 53 transmits the charging packet stored in its memory and the charging packet stored in the local operation management server 54 to the restored charging server 1 55.

The regional operation management server 54 manages a plurality of gateways 51, 52, and 53 using the SNMP protocol. One gateway detects the downtime of the billing server and notifies the local operations management server, and the local operations management server notifies all other gateways and checks the recovery of the charging server. As a result, as described above, all gateways other than one gateway among the gateways managed by the regional operation management server transmit an accounting packet when the accounting server is down to detect an overhead of detecting the accounting server when no response is received. It can reduce the overhead of continuously checking the billing server's recovery at all gateways by notifying the billing server's recovery from the local operations management server.

6 is a flowchart illustrating a charging packet transmission process from a gateway to a charging server according to the present invention. When the call is made or the call is terminated at the gateway, the charging packet is generated and transmitted to the redundant charging server. One embodiment of the process is shown. Referring to FIG. 6, the H323 task 32 checks a call state (S601) and determines whether a call has started or terminated (S602). If it is determined in step S602 that the call is not started or terminated, the process is terminated (S603). On the contrary, if it is determined in step S601 that the call is started or terminated (S602), the corresponding billing starts. The charging information related to the packet or the charging termination packet is collected (604), and transmitted to the RADIUS task 35 through the RADIUS queue 34 (S605). The RADIUS task 35 finds a charging packet 42 whose flag 43 is free in the charging information table 41 by filling the charging information from the RADIUS queue 34 to fill the header value 44 (S606). ).

Then, each attribute is generated using the charging information obtained from the H323 task 32 (S607), and each attribute is connected to a list linked to the corresponding charging packet 42 of the charging information table 41, thereby charging the charging packet ( 42) (S608). Subsequently, it is determined whether the charging server having the highest priority is alive (S609). If it is determined in the step S609 that the high priority billing server is not alive, the high priority accounting server is down processed (S610). On the contrary, as a result of the determination in the step S609, the high priority billing server is determined. If alive, a UDP (User Datagram Protocol) socket is created (S611), the charging packet 42 is transmitted to the charging server (S612), and the response server is waited for from the charging server (S613).

Subsequently, it is determined whether a response packet is received from the high charging server (S614). As a result of the determination in step S614, when the response packet is received from the charging server, the memory allocated to generate the attribute is released, and the flag value of the corresponding charging packet 42 in the charging information table 41 is changed to free for charging. Complete the packet transmission (S616).

However, when a response packet is not received from the charging server of the high priority as a result of the determination in step S614, the local operation management server 54 is notified of the down of the charging server of the high priority (S615). In step S609, it is determined whether the low priority accounting server is alive (609). The following process is also repeated for the low priority billing server. That is, when the low priority accounting server is not alive, the processing server is down (S610). On the contrary, when the low priority server is alive, a UDP socket is generated in the same manner as described above (S611). ), The charging packet 42 is transmitted to the low priority charging server (S612), and the response packet is waited for from the low priority charging server (S613). Subsequently, upon receiving the response packet, the flag value of the corresponding charging packet in the memory release and charging information table is changed to free to complete the charging packet transmission (S616). However, if the response packet is not received, the down-priority charging server is notified to the local operation management server 54 (615), and checks whether all the charging servers are down and performs the charging server down task (S610). .

7 is a flowchart illustrating a charging packet processing process when the charging server is down according to the present invention. As shown in FIG. 7, when all of the charging servers are down, the gateway generates a related charging packet when the call starts or ends, and then checks the threshold of the charging information table in its memory (S701). It is determined whether the amount of the charging packet generated after the charging server is down exceeds the threshold of the memory (S702). If it is determined in step S702 that the amount of the generated charging packet exceeds the threshold of the memory, the charging packet stored in the charging information table is transmitted to the local operation management server (S703), and is allocated to generate an attribute. The memory is released and the flag value of the charging information table is changed to free (S704).

However, if it is determined in step S702 that the amount of the generated charging packet does not exceed a threshold, the generated charging packet is stored in the charging information table of the memory. Preferably, the charging packet is stored in a file format in a local operation management server using a Trivial File Transfer Protocol (TFTP).

8 is a flowchart showing a charging packet processing process when recovering a charging server according to the present invention. When the charging server that has been down is restored, as shown in FIG. 8, the local operation management server notifies each gateway of the recovery of the charging server (S801). The gateway knows that the billing server has been restored through this, indicates that the billing server has been restored, and checks whether there is a billing packet to be sent to the billing server in the billing information table of its memory (S802). Next, it is determined whether there is a charging packet in which the flag value of the charging information table is set to Used (S803). As a result of the determination in step S803, if there is no charging packet in which the flag value is set to Used, that is, if there is no charging packet to be transmitted to the charging server, it is determined whether the charging packet is stored in the local operation management server (S806). However, if there is a charging packet in which the flag value is set to Used as a result of the determination in step S803, that is, if there is a charging packet to be transmitted to the charging server in the charging information table, the charging packet is transmitted to the restored charging server (S804). In step S805, the controller 100 determines whether the charging packet is stored in the local operation management server after releasing the allocated memory when the attribute is generated and changing the flag value of the charging information table to Free (S805). .

If the charging packet is not stored in the regional operation management server as a result of the determination of step S806, the process ends. On the contrary, if the charging packet is stored in the regional operation management server, the local operation is determined. The charging packet is obtained from the management server (S807), and the charging packet is transmitted to the restored charging server (S808). Bring the billing packet file stored in the local operation management server through TFTP, store it in the memory of the gateway and send the billing packet to the billing server without any modification.

As described above, according to the present invention, even if there is a single charging server as well as a redundant charging server for stabilization, the gateway detects the down of the charging server when all of the charging servers are down and the local operation management server. If the billing packet is stored in the memory of the gateway, and the threshold value of the allocated memory is exceeded, the billing packet is stored in a file format in the local operation management server to prevent the loss of the billing packet. In addition, if the billing server is down, one gateway detects the downtime of the billing server and notifies the regional management server, and the regional management server notifies all other gateways of the charging server down and periodically checks the recovery of the billing server. Use

In the detailed description and drawings of the present invention, the charging packet transmission method between the gateway and the charging server when the charging server is down is limited to two redundant charging servers, but the charging server of the present invention can be used in various numbers in a communication system. In addition, a plurality of gateways may be used and applied. The redundant billing server as described above is merely a preferred example for explaining the present invention and does not limit the scope of the present invention.

Therefore, the scope of the present invention should be determined by the appended claims rather than by the foregoing description.

According to the present invention, if the VoIP gateway does not have a file system or a disk device, the charging packet after the charging server is down is stored in its memory and the file is stored in the local operation management server when the threshold of the allocated memory is exceeded. By storing in the form, there is an effect of preventing the loss of the charging packet.

In addition, among the gateways managed by the regional operation management server, all the gateways except one gateway transmit a charging packet when the charging server is down, thereby reducing the overhead of detecting the down of the charging server when no response is received. Since the management server continuously checks and reports the recovery of the charging server, there is an effect of reducing the overhead of continuously checking the recovery of the charging server at all gateways.

Claims (17)

Claims [1] A method of transmitting a charging packet between at least one gateway having no file system or a disk device and a charging server in a communication system having at least one charging server. A first step of the gateway informing the local operations management server of the downtime of the charging server when all of the one or more charging servers are down; A second step of storing the charging packet stored in the memory in the local operation management server when the amount of the charging packet generated after all the charging servers are down exceeds the threshold of the allocated memory of the gateway; And And when a charging server of at least one of the down billing servers is restored, transmitting a charging packet stored in the memory and a charging packet stored in the local operation management server to the restored charging server. Billing packet transmission between the billing server and the billing server. The method of claim 1, wherein the first step is The first gateway of the one or more gateways detects the down of the billing server and informs the local operations management server of the down of the billing server, and the local operations management server informs all other gateways of the down of the billing server and the billing server. Billing packet transmission method between the gateway and the billing server, characterized in that periodically check the recovery of. The method of claim 1, wherein the second step, One or more gateways receiving down information of all the billing servers from the local operation management server store the billing packets generated after the down of the billing server in its memory, and the threshold value of the billing information table allocated to the memory is exceeded. And storing the stored charging packet in the local operation management server. The method of claim 3, And the memory of the gateway transmits the charging packet stored up to a threshold value to the local operation management server and stores the charging packet generated later. The method of claim 1, And the charging packet comprises a flag, a charging packet header, and a pointer. The method of claim 1, wherein the third step is The regional operation management server detects the recovery of the charging server and notifies all gateways, and the gateway takes the charging packet stored in the memory and the local operation management server and transmits it to the restored charging server. Method of transmitting billing packet between. The method of claim 1, wherein the third step is When the billing server is restored, the gateway indicates the restoration of the billing server and checks the flag value of the billing packet in the billing information table of the gateway, and if a billing packet exists, sends the billing packet to the restored billing server. Charging packet transmission method between the gateway and the charging server. The method of claim 7, wherein After transmitting the charging packet existing in the charging information table, check whether the charging packet is stored in the local operation management server, take the stored charging packet, store it in the memory, and transmit it to the recovered charging server without any modification. Billing packet transmission method between the gateway and the billing server, characterized in that. Claims [1] A method of transmitting a charging packet between at least one gateway having no file system or a disk device and a charging server in a communication system having a redundant charging server. A first step in which, by the first charging server having a high priority, the gateway notifies the local operation management server of the downtime of the first charging server and transmits a later charging packet to the second charging server having a lower priority; If the second billing server is down after the first step, the gateway notifies the local operations management server of the downtime of the second billing server and the amount of billing packets generated thereafter exceeds a threshold of the allocated memory of the gateway. A second step of storing the excess charging packet in the local operation management server if And And when the at least one charging server is restored, transmitting the charging packet stored in the memory and the charging packet stored in the local operation management server to the restored charging server. Packet transmission method. The method of claim 9, wherein the first step is When the gateway detects the down of the first billing server and informs the local operations management server of the down of the first billing server, the local operations management server informs other gateways of the gateway and the billing server. How to send billing packet. The method of claim 9, The regional operation management server checks the recovery of the down billing server and notifies the gateway of the recovery of the charging server, characterized in that the charging packet transmission method between the gateway and the charging server. The method of claim 9, wherein the second step, When all of the billing servers are down, the gateway, which detects down, notifies the local operation management server, stores a billing packet generated thereafter in a memory, and if the threshold of the allocated billing information table of the memory is exceeded, the stored billing packet. Charging packet transmission method between the gateway and the charging server, characterized in that for storing in the local operation management server. The method of claim 12, And the memory of the gateway transmits the charging packet stored up to a threshold value to the local operation management server and stores the charging packet generated later. The method of claim 9, wherein the third step, When the regional management server detects the recovery of the charging server, the gateways are notified to all the gateways of the recovery of the charging server, and the gateways take the charging packets stored in the memory and the regional management server and transmit them to the restored charging server. Billing packet transmission method between the gateway and the billing server, characterized in that. The method of claim 9, When the billing server is restored, the gateway indicates recovery of the billing server and checks a flag value of a billing packet of its own billing information table, and if a billing packet exists, transmits the billing packet to the restored billing server. Charging packet transmission method between the gateway and the charging server. The method of claim 15, After transmitting the charging packet existing in the charging information table, check whether the charging packet is stored in the local operation management server, take the stored charging packet, store it in the memory, and then to the restored charging server without any modification. Billing packet transmission method between the gateway and the billing server, characterized in that for transmitting. In a communication system having a processor to manage a redundant billing server, A first function of the gateway notifying the local operation management server of the downtime of the first billing server and transmitting a billing packet generated after the first billing server having a higher priority to the second billing server having a lower priority; If the second billing server is down after the first step, the gateway notifies the local operations management server of the downtime of the second billing server and the amount of billing packets generated thereafter exceeds a threshold of the allocated memory of the gateway. A second function of storing the excess charging packet in the local operation management server if And A third function of transmitting a charging packet stored in the memory and a charging packet stored in the local operation management server to the restored charging server when at least one charging server is restored; A computer-readable recording medium having recorded thereon a program for executing the program.