JP7247477B2 - Control device, billing acquisition method, billing acquisition program and billing system - Google Patents

Description

The present invention relates to a control device, a charge acquisition method, a charge acquisition program, and a charge system.

The reference point Ga (Reference point between a CDF and the CGF for CDR transfer) in the offline charging architecture of 3GPP (Third Generation Partnership Project) networks is specified in 3GPP TS 32.295. Offline charging is a charging mechanism in which charges are charged through detailed records (charging data records (CDRs)) such as the start and end times of calls (telephones), like monthly billing. Offline billing does not immediately affect the service being communicated during communication, and unpaid service charges after billing may cause the service to become unusable. Ga is the reference point from the Charging Data Function (CDF) to the Charging Gateway Function (CGF) and is used for the transfer of Charging Data Records (CDRs).

FIG. 23 is a diagram illustrating an offline charging architecture. As shown in Figure 23, the CTF (Charging Trigger Function) collects information about chargeable events within a network element, assembles this information into corresponding charging events, and provides an Rf (Reference Point between the CTF within a 3G network). element and the CDF for offline charging) to transfer to the CDF via a reference point. The CDF (Charging Data Function) receives charging events from the CTF via the Rf reference point, generates CDRs using the information contained in the received Charging events, and passes the CGF (Charging Gateway) through the Ga reference point. Function). The CGF receives the CDRs generated by the CDF through the Ga reference point, verifies, consolidates, reformats, etc. the received CDRs, generates a CDR file and converts it to Bx (The reference point between any (generic) 3G domain, subsystem or service CGF and the BD) reference point to the BD (Billing Domain).

Transfer of CDR packets in the network shown in FIG. 23 will be specifically described. First, the CDF sends the CDR to the CGF using a Data Record Transfer Request message. The CGF then stores the received CDRs, such as in redundant random access memory (RAM) memory units or mirrored non-volatile memory. The stored CDRs are converted to Bx format for transfer to BD. The CGF then sends CDR reception success to the CDF using a Data Record Transfer Response message. The Cause value at this time is "Request Accepted". After receiving Request Accepted, the CDF deletes the successfully transmitted CDRs from the transmission buffer. In this way the CDRs generated by the CDF are sent to the CGF in real time. It should be noted that GTP prime (GTP') is used as the transport protocol associated with the Ga reference point that provides the functionality for CDR transfer from CDF to CGF. In recent years, the CGF is also made redundant in preparation for failures such as system failures and link failures.

JP 2010-147644 A Japanese Patent Publication No. 2010-515355

By the way, after the communication between the CDF and CGF that was interrupted due to the failure is restored, the old CDR that was not transmitted due to the failure and the new CDR that was newly generated until the failure is recovered may coexist. With the above technology, even if the old CDRs are retained in the CDF backup storage, there is no provision for a protocol to automatically transfer them to the CGF after recovery. It is converted into a format and transmitted to BD.

It is also conceivable that the CDF saves the old CDR in the backup storage and sends the old CDR and the new CDR to the CGF after recovery from the failure, but this method causes a delay in sending the new CDR. For example, assume that a failure occurs while transmitting a CDR with sequence number 100, and CDRs up to sequence number 500 are generated during the failure. In this case, the CDF stores 400 old CDRs with sequence numbers from 100 to 500, and sequentially transmits them after recovery from the failure. However, after recovery from the failure, the newly generated new CDR with the sequence number 501 will be sent after the transmission of the 400 old CDRs accumulated at the time of the failure, and real-time transmission cannot be executed.

In 3GPP, 1 minute is set as "near real time" for CDR transmission, and this restriction cannot be complied with as the number of CDRs accumulated at the time of failure increases. It is also conceivable to discard the accumulated CDRs at the time of failure, but this is not a preferable method because it will not be possible to perform billing correctly if the CDRs are discarded.

An object of one aspect is to provide a control device, a charge acquisition method, a charge acquisition program, and a charge system capable of suppressing transmission delay of charge information.

In the first scheme, the control device includes a receiving unit that receives the billing information via a first connection established with a billing generation device that generates billing information used for billing communication charges. have The control device establishes the first connection and the second connection with the charge generation device when the communication with the charge generation device is restored after the communication with the charge generation device is interrupted. has an established part that The control device receives, via the first connection, first billing information generated after the communication is restored, and via the second connection, the first billing information generated during the disconnection of the communication. and a reception control unit that acquires the second billing information.

According to one embodiment, transmission delay of billing information can be suppressed.

FIG. 1 is a diagram illustrating the system configuration of offline charging architecture according to the first embodiment. FIG. 2 is a diagram showing transmission paths of CDRs. FIG. 3 is a functional block diagram of functional configurations of CDF and CGF according to the first embodiment. FIG. 4 is a diagram for explaining the connection establishment relationship from normal operation to after failure recovery. FIG. 5 is a flowchart illustrating the overall flow of processing when a CDF failure occurs according to the first embodiment. FIG. 6 is a flowchart illustrating the overall flow of processing when a CGF failure occurs according to the first embodiment; FIG. 7 is a sequence diagram of a flow when a communication failure occurs according to the first embodiment; FIG. 8 is a diagram showing a format example of the Data Record Transfer Request. FIG. 9 is a diagram showing a format example of Redirection Request. FIG. 10 is a diagram showing a format example of the Data Record Transfer Request. FIG. 11 is a diagram showing a format example of the Data Record Transfer Response. FIG. 12 is a sequence diagram of the flow at the time of system failure according to the first embodiment. FIG. 13 is a diagram showing a format example of the Node Alive Response. FIG. 14 is a sequence diagram illustrating the flow at the time of communication failure in the CGF redundant system according to the second embodiment; FIG. 15 is a sequence diagram of the flow at the time of system failure in the CGF redundancy system according to the second embodiment; FIG. 16 is a sequence diagram illustrating a flow when a communication failure is initiated by a maintenance terminal according to the third embodiment; FIG. 17 is a sequence diagram illustrating a flow of processing when there is no saved CDR at the initiative of the maintenance terminal according to the third embodiment; FIG. 18 is a sequence diagram illustrating a flow of deletion of a saved CDR led by a maintenance terminal according to the third embodiment; FIG. 19 is a sequence diagram illustrating a flow when a transmission error occurs after failure recovery according to the fourth embodiment; FIG. 20 is a sequence diagram illustrating the flow when a response error occurs after failure recovery according to the fourth embodiment. FIG. 21 is a sequence diagram illustrating the flow when an error occurs at the end of saving CDR according to the fourth embodiment. FIG. 22 is a diagram illustrating a hardware configuration example. FIG. 23 is a diagram illustrating an offline charging architecture.

Exemplary embodiments of a control device, a billing acquisition method, a billing acquisition program, and a billing system disclosed in the present application will be described below in detail with reference to the drawings. In addition, this invention is not limited by this Example. Moreover, each embodiment can be appropriately combined within a range without contradiction.

[overall structure]
FIG. 1 is a diagram illustrating the system configuration of offline charging architecture according to the first embodiment. The system shown in Fig. 1 consists of RNC (Radio Network Controller), SGSN (Serving GPRS Support Node), eNodeB (E-UTRAN NodeB), EPC (Evolved Packet Core), other EPC, BD (Billing Domain), VGN (VoLTE Gateway Node) and ISP (Internet Service Provider), it is an offline billing system that collects detailed records (CDR) used for monthly billing such as voice calls and bills.

RNC is a control station that controls the entire wireless communication network. The SGSN is a device that performs mobility management and authentication (security control) of terminals in 3G wireless access. eNodeB is a base station used in mobile phone communications using LTE (Long Term Evolution). EPC is a core network that accommodates LTE access networks. BD is a billing system that includes a billing device that collects billing information and bills. VGN is a gateway node for implementing voice calls using LTE data communication. An ISP is a business that provides Internet users with a means of connecting their computers to the Internet as a service.

In addition, EPC is MME (Mobility Management Entity), PCRF (Policy and Charging Rule Function) / DRA (Diameter Routing Agent), S-GW (Serving Gateway), P-GW (Packet Data Network Gateway), CDF10, CGF30 have. The MME performs terminal mobility management, authentication (security control), user data transfer route setting processing and control signal processing between the S-GW and eNodeB. The PCRF is a policy control device that determines policy control such as QoS and charging control rules applied in the P-GW and S-GW. A DRA is a Diameter routing agent, a device that controls and manages Diameter signaling. S-GW is a device that accommodates 3GPP radio such as LTE and 3G radio and transmits user data. The S-GW is also a switching point for user data transfer paths to LTE and 3G radio access accommodation networks. The P-GW is a device that serves as a connection point with a packet network (PDN: packet data network) outside the core network such as IMS (IP Multimedia Subsystem). The P-GW is a gateway device that allocates IP addresses and accommodates 3GPP access and non-3GPP access.

The CDF 10 is a device that receives a Charging event from the CTF via the Rf reference point, generates a CDR using information contained in the received Charging event, and transfers it to the CGF via the Ga reference point. CGF 30 receives CDR generated by CDF via Ga reference point, verifies, integrates, reformats, etc. the received CDR, generates CDR file and transfers to BD via Bx reference point. It is a device that

In addition, the CDF 10 is arranged in different positions within the system depending on the implementation form of the network element for which charging is defined by the 3GPP standard. Even in such a case, the CDR transmission route can be identified by the position of the Ga reference pointer from CDF10 to CGF30. FIG. 2 is a diagram showing transmission paths of CDRs. FIG. 2(a) shows an example system in which the CDF 10 is integrated with other network elements. In this case the physical NE generates CDRs and sends them to the CGF. Therefore, the Ga reference pointer is implemented within the NE as a physical interface.

FIG. 2(b) shows a system example in which the CDF 10 exists as a network element. In this case, we implement all reference points as physical interfaces of NE, CDF 10 and CGF 30 . That is, the NE uses the Rf reference pointer to send charging events collected from within the system to the CDF 10 . CDF 10 generates CDRs from charging events and sends them to CGF 30 via Ga reference points. The CGF 30 performs predetermined processing on the CDR received from the CDF 10 and transmits it to the BD via the Bx reference pointer.

Embodiment 1 can be applied to any of the above cases, and Embodiment 1 will be described with reference to FIG. 2B as an example.

In such a system, the CGF 30 receives billing information via the first connection established with the CDF 10 that generates billing information used for billing communication charges. The CGF 30 establishes a first connection and a second connection with the CDF 10 when the communication with the CDF 10 is restored after the communication with the CDF 10 is cut off. After that, the CGF 30 receives the first billing information generated after the communication is restored via the first connection, and via the second connection the second billing information generated during the interruption of the communication. Get billing information for

In other words, after recovery from the failure, the CGF 30 establishes a second connection with the CDF 10 that is different from the first connection normally used using available resources such as bandwidth and memory. Then, the CGF 30 receives the normal CDR generated after recovery from the failure through the same first connection as before the occurrence of the failure. On the other hand, the CGF 30 receives the CDRs that were generated and saved during the failure through the second connection different from the normal first connection.

By doing so, the CGF 30 can normally receive the CDRs generated during the failure without affecting normal CDR reception, and can also receive the CDRs normally generated after the failure is restored. be received without delay.

[Function configuration]
Next, each element (apparatus) of the system shown in FIG. 1 will be described. Since elements other than the CDF 10 and CGF 30 have the same configuration as the elements used in the 3GPP billing architecture, a detailed description will be given. are omitted. Here, the CDF 10 and the CGF 30 will be explained using FIG. FIG. 3 is a functional block diagram showing functional configurations of the CDF 10 and CGF 30 according to the first embodiment.

(Functional configuration of CDF10)
As shown in FIG. 3, the CDF 10 has a communication section 11, a storage section 12, and a control section 20. FIG. The communication unit 11 is a processing unit that controls communication with another device via a network. For example, the communication unit 11 receives billing events from the CTFs of S-GW and P-GW, and transmits CDRs to the CGF 30 . Also, the communication unit 11 executes transmission/reception of connection establishment requests and various messages with the CGF 30 . Also, the communication unit 11 establishes a GTP connection with the CGF 30 and transmits the CDR.

The storage unit 12 is an example of a storage device that stores programs and data, such as a memory or a hard disk. This storage unit 12 stores the CDR generated by the control unit 20 . Further, the storage unit 12 stores a save DB 13 . The save DB 13 is a storage unit that stores CDRs that have not been transmitted to the CGF 30 due to a failure or the like (hereinafter sometimes referred to as save CDRs). For example, the save DB 13 temporarily stores the CDRs in the order in which they were generated.

The control unit 20 is a processing unit that controls the entire CDF 10, such as a processor. The control unit 20 has an event reception unit 21 , a CDR generation unit 22 , a CDR transmission unit 23 and a failure processing unit 24 . Note that the event reception unit 21, the CDR generation unit 22, the CDR transmission unit 23, and the fault processing unit 24 are examples of electronic circuits possessed by the processor and processes executed by the processor.

The event reception unit 21 is a processing unit that receives billing events from the CTF. Specifically, when a billable event such as a call between terminals occurs, the event reception unit 21 receives a billing event, which is information about the billable event, from the CTF. For example, when a voice call occurs between users, the event reception unit 21 receives from the CTF a billing event that notifies the usage status of network resources required for communication, such as the start and end of a session.

The CDR generation unit 22 is a processing unit that generates CDRs based on the billing event received by the event reception unit 21 . For example, the CDR generation unit 22 acquires a billing event from the event reception unit 21, and generates a CDR including information necessary for billing such as call duration, call time zone, call partner, and the like. The CDR generator 22 then outputs the generated CDR to the CDR transmitter 23 .

The CDR transmission unit 23 is a processing unit that transmits CDRs to the CGF 30 via a GTP connection (GTP tunnel). For example, the CDR transmission unit 23 transmits the CDR input from the CDR generation unit 22 to the CGF 30 via the GTP connection normally established between the CDR 10 and CGF 30 . In addition, the CDR transmission unit 23 transmits the CDR while complying with the delay time defined by 3GPP, such as within one minute after the CDR is generated.

The failure processing unit 24 has a CDR save unit 25 and a failure handling unit 26, and is a processing unit that detects a communication failure between the CDF 10 and the CGF 30 or a system failure of the CDR 10 or CGF 30 and executes failure handling. For example, the fault processing unit 24 detects a fault when a reception response cannot be received from the CGF 30 within a predetermined time after transmitting the CDR. Further, when the failure processing unit 24 receives a failure recovery notification, a CDR retransmission request, or the like from the CGF 30, it determines that the failure has been recovered.

The CDR saving unit 25 is a processing unit that saves CDRs when a failure is detected. For example, when a failure is detected, the CDR saving unit 25 saves the CDRs generated until the failure is recovered in the saving DB 13 . At this time, the CDR saving unit 25 can also manage the CDRs to be saved by assigning a sequential number to each CDR to be saved in the order of generation, ie, the order of transmission.

The failure handling unit 26 is a processing unit that manages connections and the like and transmits saved CDRs at the time of failure recovery. Specifically, when communication with the CGF 30 is restored, the failure handling unit 26 establishes a GTP connection with the CGF 30 that is normally used. Then, the failure handling unit 26 instructs the CDR transmission unit 23 to perform normal processing. As a result, CDRs generated after failure recovery are transmitted using the same GTP connection as normal.

After recovery from the failure, the failure handling unit 26 establishes a saved GTP connection for CDR transmission with the CGF 30 in response to a request from the CGF 30 in parallel with the above processing. Then, the failure handling unit 26 transmits each save CDR stored in the save DB 13 to the CGF 30 via the newly saved save GTP connection. That is, the failure handling unit 26 establishes a new saving GTP connection using unused resources such as unused bandwidth and memory, and retransmits the unsent CDRs via the saving GTP connection.

At this time, the failure handling unit 26 can transmit the saved CDRs in the order of the managed sequential numbers, thereby transmitting the CDRs in the order of generation. Further, when the transmission of all the saved CDRs stored in the saving DB 13 is completed, the fault handling unit 26 disconnects the saving GTP connection. As a result, the GTP connection between the CDF 10 and the CGF 30 is the same as before the occurrence of the failure, with only the GTP connection normally used being established.

(Functional configuration of CGF30)
As shown in FIG. 3, the CGF 30 has a communication section 31, a storage section 32, and a control section . The communication unit 31 is a processing unit that controls communication with another device via a network. For example, the communication unit 31 executes transmission and reception of connection establishment requests and various messages with the CDF 10 . Also, the communication unit 31 establishes a GTP connection with the CDF 10 and receives the CDR. Also, the communication unit 31 controls communication with the BD.

The storage unit 32 is an example of a storage device that stores programs and data, such as a memory or a hard disk. The storage unit 12 stores a CDR storage DB 33 that stores received CDRs. The CDR storage DB 33 holds the CDR received from the CDF 10 until it is sent to the BD.

The control unit 40 is a processing unit that controls the entire CGF 30, such as a processor. The control unit 40 has a normal processing unit 50 and a failure processing unit 60 . Note that the normal processing unit 50 and the failure processing unit 60 are an example of an electronic circuit possessed by a processor and an example of a process executed by the processor.

The normal processing unit 50 has a CDR receiving unit 51 and a CDR processing unit 52, and is a processing unit that receives CDRs from the CDF 10 and transmits them to the BD as usual before a failure occurs or after failure recovery.

The CDR receiving unit 51 is a processing unit that establishes a GTP connection with the CDF 10 and receives CDRs via the GTP connection. For example, the CDR receiving unit 51 sequentially receives the CDRs transmitted in compliance with the 3GPP delay time from the CDF 10 in the order in which they were generated. Then, the CDR receiver 51 stores the received CDRs in the CDR storage DB 33 in order of reception.

The CDR processing unit 52 is a processing unit that transmits the CDR received from the CDF 10 to the BD via the Bx reference point. For example, the CDR processing unit 52 reads CDRs stored in the CDR storage DB 33, and performs various processes such as CDR verification, integration, and reformatting on the read CDRs. After that, the CDR processing unit 52 transmits the CDR converted into the Bx format to the BD. At this time, the CDR processing unit 52 executes various processes and transmits the CDRs to the BD in the order in which they were generated. Note that the various processes described above are similar to general processes executed in 3GPP offline billing, so detailed description thereof will be omitted.

The failure processing unit 60 has a protocol control unit 61 and a CDR handling unit 62, and is a processing unit that detects a communication failure between the CDF 10 and the CGF 30 or a system failure of the CDR 10 or CGF 30 and executes failure handling. For example, the fault processing unit 60 detects a communication fault when the next CDR is not received within a predetermined time that is specified in advance after the CDR is received. Further, the fault processing unit 60 detects a fault when an error occurs in transmission and reception of various data (packets) due to a system fault of the CGF 30 . Further, when a communication failure or a system failure is recovered, the failure processing unit 60 transmits a GTP connection establishment request, a CDR retransmission request, and the like to the CDF 10 .

The protocol control unit 61 is a processing unit that establishes a GTP connection after failure recovery. For example, when the failure recovery is detected by the failure processing unit 60, the protocol control unit 61 re-establishes the GTP connection with the CDF 10 that was established normally before the failure occurred. As a result, CDRs newly generated by the CDF 10 after a failure can be received through normal GTP connections.

In parallel with the establishment of the normal GTP connection, the protocol control unit 61 establishes the GTP connection for evacuation after recovery from the failure. For example, when the fault is restored, the protocol control unit 61 sends the CDF 10 a request to establish a connection for evacuation. Then, when the protocol control unit 61 receives a response to the request from the CDF 10, the protocol control unit 61 establishes an evacuation GTP connection for transmission of the evacuation CDR with the CDF 10 using free resources such as unused bandwidth and memory. establish between After that, when the transmission of the CDR saved during the failure is completed, the protocol control unit 61 disconnects the saving GTP connection to release the resource.

The CDR handling unit 62 is a processing unit that executes processing related to the saved CDRs saved in the CDF 10 after failure recovery. For example, when the GTP connection for saving is established, the CDR support unit 62 receives the CDR (saved CDR) generated and saved during the occurrence of the failure via the GTP connection for saving. Then, the CDR handling unit 62 assigns a sequential number or the like to the received saved CDRs in order of reception and stores them in the CDR storage DB 33 . In this way, the CDR handling unit 62 manages the reception status of the saved CDRs that have been saved. Note that the CDR (saved CDR) stored in the CDR storage DB 33 is sent to the BD by the CDR processing unit 52 before the newly generated CDR (new CDR) after the occurrence of the failure. In this way, the CDRs can be transmitted to the BD in the order in which they were generated.

[Connection Status]
Next, the establishment relationship of the GTP connection will be described with reference to FIG. FIG. 4 is a diagram for explaining the connection establishment relationship from normal operation to after failure recovery. As shown in FIG. 4, under normal conditions before a failure occurs, one GTP connection is always established between the CDF 10 and the CGF 30, and CDR transmission/reception is executed.

Then, when a failure occurs and the GTP connection is disconnected, the CDF 10 saves the generated CDR in the save DB 13 and suppresses transmission to the CGF 30 . After that, when the failure is restored, the CGF 30 establishes two connections with the CDF 10, a normal GTP connection and a saving GTP connection.

Then, the CDF 10 uses the normal GTP connection to send the CDRs generated after the occurrence of the failure to the CGF 30, and uses the saving GTP connection to send the saved CDRs saved at the time of the failure to the CGF 30. .

After that, when the CGF 30 completes receiving all the saved CDRs, the CGF 30 disconnects only the saving GTP connection. As a result, the connection between the CDF 10 and the CGF 30 will be in the same state as before the failure occurred.

[flowchart]
Next, for each of the CDF 10 and CGF 30, the overall flow of processing when a failure occurs will be described.

(Flowchart of CDF10)
FIG. 5 is a flowchart illustrating the overall flow of processing when a failure occurs in the CDF 10 according to the first embodiment. The CDF 10 saves all CDRs in the storage of the CDF 10 or external storage when communication with the CGF 30 is cut off for a certain period of time.

As shown in FIG. 5, the failure processing unit 24 of the CDF 10 transmits a Data Record Transfer Request to the CGF 30 (S101), and sets a reception waiting timer for the Data Record Transfer Response, which is a response message (S102).

After that, when the response message has not been received and the reception wait timer has expired (S103: Yes), the failure processing unit 24 transmits a Data Record Transfer Request to the CGF 30 (S104), and the response message Data Record Transfer Response is set (S105).

Then, if the response message has not been received, the reception wait timer has expired, and the number of retransmissions has expired (S106: Yes), the fault processing unit 24 detects the occurrence of a fault with the CGF 30 (S107). After that, the failure processing unit 24 saves the CDR generated by the CDR generation unit 22 during the failure to the backup DB 13 (S108).

Then, the failure processing unit 24 periodically transmits an Echo Request to the CGF 30 (S109). Here, when the failure processing unit 24 receives a Node Alive Request from the CGF 30 (S110: Yes), failure recovery is detected (S111). Subsequently, after transmitting a Node Alive Response to the CGF 30 (S112), the fault processing unit 24 transmits a Data Record Transfer Request (empty packet) to the CGF 30 (S113). As a result, a GTP connection different from that normally used is established.

On the other hand, when the failure processing unit 24 receives the Echo Response from the CGF 30 (S114: Yes), it detects failure recovery (S115). Subsequently, the failure processing unit 24 transmits a Data Record Transfer Request (empty packet) to the CGF 30 (S116). As a result, a GTP connection different from that normally used is established.

(CGF30 flow chart)
FIG. 6 is a flow chart showing the overall flow of processing when a failure occurs in the CGF 30 according to the first embodiment. The CGF 30 makes it possible to collect CDRs saved automatically or manually by maintenance personnel. Here, the flow at the time of system failure and the flow at the time of communication failure will be described together, but the present invention is not limited to this, and determination can be made using separate flows.

As shown in FIG. 6, when the normal processing unit 50 of the CGF 30 receives a Data Record Transfer Request from the CDFG 10 (S201), it stores the CDR in the CDR storage DB 33 and transmits a Data Record Transfer Response to the CDF 10 (S202).

After that, when the failure processing unit 60 of the CGF 30 cannot receive the Data Record Transfer Request from the CDF 10 (S203: Yes), it detects a communication failure (S204). After that, when receiving an Echo Request from the CDF 10 (S205: Yes), the failure processing unit 60 detects failure recovery (S206) and transmits an Echo Response to the CDF 10 (S207).

After that, when receiving a Data Record Transfer Request (empty packet) from the CDF 10 (S208: Yes), the fault processing unit 60 transmits a Data Record Transfer Response to the CDF 10 (S209).

Then, if the save CDR exists (S210: Yes), the failure processing unit 60 executes save processing including establishment of a GTP connection for saving (S211), and if the save CDR does not exist (S210: No). , terminate the process.

On the other hand, when the normal processing unit 50 of the CGF 30 receives the Data Record Transfer Request from the CDFG 10 (S212), it executes normal processing. After that, assume that a system failure occurs in the CGF 30 (S213).

When the system failure is recovered (S214: Yes), the failure processing unit 60 transmits a Node Alive Request to the CDF 10 (S215), and when receiving a Node Alive Response from the CDF 10 (S216), executes S208 and subsequent steps.

[Sequence diagram (communication failure)]
FIG. 7 is a sequence diagram of a flow when a communication failure occurs according to the first embodiment; As shown in FIG. 7, assume that a communication failure occurs between the CDF 10 and the CGF 30 (S301), and then the failure is recovered (S302), and communication becomes possible.

Then, the CDF 10 transmits to the CGF 30 the Echo Request that was repeatedly retransmitted during the failure (S303 and S304). Upon recovery from the failure, the normal processing unit 50 of the CGF 30 that has received this Echo Request returns an Echo Response to the CDF 10 (S305 and S306).

Subsequently, the failure processing unit 24 of the CDF 10 transmits a Data Record Transfer Request (empty packet) to the CGF 30 (S307 and S308). At this time, by setting the Save CDR Information IE, which is an option IE (Information Element), the CGF 30 is notified of the existence of the save CDR. FIG. 8 is a diagram showing a format example of the Data Record Transfer Request. As shown in FIG. 8, "Save CDR Information" is newly added to Data Record Transfer Request as an IE (Information Element) in addition to existing items such as Packet Transfer Command. The CGF 30 can detect that a save CDR exists when this "Save CDR Information" is set in the Data Record Transfer Request. "Save CDR Information" can be specified by an 8-bit Type.

After that, a normal GTP connection is re-established between the CDF 10 and the CGF 30, and the CDR generated after the failure is transmitted via the normal GTP connection (S309).

In parallel with this normal processing, the failure processing unit 60 of the CGF 30 transmits a connection request for saving to the CDF 10 (S310 and S311), and the failure processing unit 24 of the CDF 10 transmits a response to the connection request to the CGF 30 (S310 and S311). S312 and S313). As a result, the failure processing unit 60 of the CGF 30 establishes a GTP connection for saving with the CDF 10 (S314).

Subsequently, the failure processing unit 60 of the CGF 30 transmits Redirection Request to the CDF 10 (S315 and S316). At this time, the Cause IE of the message is set to "Saved CDR transfer request" to request the CDF 10 to transfer the saved CDR. FIG. 9 is a diagram showing a format example of Redirection Request. As shown in FIG. 9, as a setting of Redirection Request, "Saved CDR transfer request" is newly added in addition to the existing items such as Address of Recommended Node. The CDF 10 can detect the save CDR request by setting this "Saved CDR transfer request" to Redirection Request.

Then, the failure processing unit 24 of the CDF 10 transmits a Redirection Response to the CGF 30 as a response to the Redirection Request from the CGF 30 (S317 and S318). At this time, "Request Accepted" is set in Cause IE. The CDF 10 also manages sequence numbers for saving CDR transfer.

After that, the failure processing unit 24 of the CDF 10 transmits the saved CDR (saved CDR) to the CGF 30 via the GTP connection for saving (S319 and S320). At this time, the CDF 10 transmits a Data Record Transfer Request in which the Packet Transfer Command IE is set to "Send Data Record Packet" to the CGF 30, and transfers the CDR (saved CDR). FIG. 10 is a diagram showing a format example of the Data Record Transfer Request. As shown in FIG. 10, "Packet Transfer Command IE" of Data Record Transfer Request can specify four pieces of information such as 1 (Send Data Record Packet).

After that, the failure processing unit 60 of the CGF 30 stores the received CDR in the CDR storage DB 33 of the storage unit 32 (S321 and S322), and transmits a Data Record Transfer Response as a reception response message to the CDF 10 (S323 and S324). At this time, "Request Accepted" is set in the Cause IE of the Data Record Transfer Response message. FIG. 11 is a diagram showing a format example of the Data Record Transfer Response. As shown in FIG. 11, the existing "Request Accepted" is set in the "Cause" of the Data Record Transfer Response and transmitted to the CDF.

After receiving the Data Record Transfer Response message, the failure processing unit 24 of the CDF 10 deletes the transferred save CDR from the save DB 13 (S325). In this way, transfer of the saved CDR (saved CDR) is executed using the GTP connection for saving.

After that, when the failure processing unit 24 of the CDF 10 transmits the last saved CDR, it sets the Packet Transfer Command IE of the Data Record Transfer Request to "Last Send Data Record Packet" and notifies the CGF 30 of the end (S326 and S327). ). As shown in FIG. 11, in addition to the existing information 1 to 4, 5 (Last Send Data Record Packet) is newly added to the "Packet Transfer Command IE" of the Data Record Transfer Request.

Subsequently, the failure processing unit 60 of the CGF 30 stores the received CDR in the CDR storage DB 33 of the storage unit 32 (S328 and S329), and transmits a Data Record Transfer Response as a reception response message to the CDF 10 (S330 and S331). . At this time, "Request Accepted" is set in the Cause IE of the Data Record Transfer Response message. The saved CDR instance data (sequence number, etc.) managed by the CGF 30 is released here.

After that, the failure processing unit 24 of the CDF 10 that received the Data Record Transfer Response message deletes the last saved CDR that has been transferred from the save DB 13 (S332). Then, the failure processing unit 60 of the CGF 30 disconnects the save GTP connection and releases the resources (S333 and S334).

[Sequence diagram (system failure)]
FIG. 12 is a sequence diagram of the flow at the time of system failure according to the first embodiment. As shown in FIG. 12, it is assumed that a system failure occurs in the CGF 30 and communication between the CDF 10 and the CGF 30 is cut off (S401), then the failure is restored (S402) and communication becomes possible.

Then, the normal processing unit 50 of the CGF 30 transmits a Node Alive Request message to the CDF 10 (S403 and S404), and the CDF 10 responds by transmitting a Node Alive Response to the CGF 30 (S405 and S406). By setting the Save CDR Information IE, which is an option IE, the CGF 30 can be notified of the existence of the save CDR. FIG. 13 is a diagram showing a format example of the Node Alive Response. As shown in FIG. 13, "Save CDR Information" is newly added to the Node Alive response as an IE (Information Element) in addition to existing items such as Node Address. The CGF 30 can detect the existence of saved CDRs when this "Save CDR Information" is set in the Node Alive response.

After that, the failure processing unit 24 of the CDF 10 transmits a Data Record Transfer Request (empty packet) to the CGF 30 (S407 and S408). At this time, instead of S405, similarly to FIG. 7, the Save CDR Information IE, which is an option IE, can be set to notify the CGF of the existence of the saved CDR.

After that, a normal GTP connection is re-established between the CDF 10 and the CGF 30, and transmission of the CDR generated after the occurrence of the failure is executed via the normal GTP connection (S409).

In parallel with this normal processing, the failure processing unit 60 of the CGF 30 transmits a connection request for saving to the CDF 10 (S410 and S411), and the failure processing unit 24 of the CDF 10 transmits a response to the connection request to the CGF 30 (S410 and S411). S412 and S413). As a result, the failure processing unit 60 of the CGF 30 establishes a GTP connection for saving with the CDF 10 (S414).

Subsequently, the failure processing unit 60 of the CGF 30 transmits Redirection Request to the CDF 10 (S415 and S416). At this time, the Cause IE of the message is set to "Saved CDR transfer Request" to request the CDF 10 to transfer the save CDR 30 .

Then, the failure processing unit 24 of the CDF 10 transmits a Redirection Response to the CGF 30 as a response to the Redirection Request from the CGF 30 (S417 and S418). At this time, "Request Accepted" is set in Cause IE. The CDF 10 also manages sequence numbers for saving CDR transfer.

After that, the failure processing unit 24 of the CDF 10 transmits the saved CDR (saved CDR) to the CGF 30 via the GTP connection for saving (S419 and S420). At this time, the CDF 10 transmits a Data Record Transfer Request in which the Packet Transfer Command IE is set to "Send Data Record Packet" to the CGF 30, and transfers the CDR (saved CDR).

After that, the failure processing unit 60 of the CGF 30 stores the received CDR in the CDR storage DB 33 of the storage unit 32 (S421 and S422), and transmits a Data Record Transfer Response as a reception response message to the CDF 10 (S423 and S424). At this time, "Request Accepted" is set in the Cause IE of the Data Record Transfer Response message.

After receiving the Data Record Transfer Response message, the failure processing unit 24 of the CDF 10 deletes the transferred save CDR from the save DB 13 (S425). In this way, transfer of the saved CDR (saved CDR) is executed using the GTP connection for saving. Since the subsequent processing is the same as in FIG. 7, detailed description will be omitted.

[effect]
As described above, when the communication failure between the CDF 10 and the CGF 30 is recovered, the CDF 10 notifies the CGF 30 that the CDR has been saved. The CGF 30 can collect automatically saved CDRs. At this time, the saved CDRs are collected by creating a new GTP tunnel from the CGF 30 to the CDF 10 without using the normal GTP tunnel for CDR transfer, and using the GTP' protocol for near real time CDR transfer. Parallel transfer is automatically possible without any influence. In other words, the CDR transfer method (GTP' protocol) at the Ga reference point of the 3GPP offline charging architecture is newly defined, and when recovering from a communication failure, without affecting the near real time transfer of newly occurring CDRs. It can be transferred to CGF30.

As a result, it is possible to transfer CDRs saved during a communication failure without affecting CDR transfer of Ga reference points, and automatically collect CDRs without loss. Also, after converting to Bx format, it can be transferred to BD. In addition, by collecting backup CDRs under the initiative of the CGF 30, it is possible to provide maintenance personnel with flexible selection.

Here, from the number of CDRs saved during a communication failure, the CDR transfer delay time when the saved CDRs are transferred according to the general protocol is calculated, and the first embodiment is compared with the general technique. First, as calculation conditions, the number of CDRs generated per hour is 1,800,000 [CDR/H], the time when communication failure occurs is 5 minutes, and the number of CDRs that can be transferred per minute at the Ga reference point is 60,000. [CDR]”.

Under these conditions, the transfer delay time of the CDRs generated in real time when the saved CDRs are transferred according to the general protocol is calculated. Since the communication failure has occurred for 5 minutes, the number of saved CDRs is 1,800,000 [CDRs]/60 [minutes]×5 [minutes]=150,000 [CDRs] (1). Next, the number of CDRs that can be transferred in one minute is 60,000 [CDR], so the time required to transfer all the saved CDRs in (1) is 150,000 [CDR] / 60,000 [CDR] = 2 minutes and 30 seconds ( 2). In addition, the number of new CDRs generated during the transfer of saved CDRs in (2) is 1,800,000 [CDR] / 60 [minutes] x 2.5 [minutes] = 75,000 [CDRs] (3). Become.

Then, the time required for transferring the CDRs in (3) is 75,000 [CDR]/60,000 [CDR]=1 minute and 15 seconds (4). Furthermore, the number of newly generated CDRs during the time when the CDRs in (4) are being transferred is 1,800,000 [CDRs]/60 [minutes] x 1.25 [minutes] = 37,500 [CDRs] (5). The time required to transfer the CDRs in (5) is 37,500 [CDR]/60,000 [CDR]=40 seconds (6). Furthermore, the number of newly generated CDRs during the time when the CDRs in (6) are being transferred is 1,800,000 [CDRs]/60 [minutes] x 0.63 [minutes] = 18,750 [CDRs] (7). The time required to transfer the CDRs in (7) is 18,750 [CDR]/60,000 [CDR]=20 seconds (8). Then, the number of CDRs newly generated during the time when the CDRs in (8) are being transferred is 1,800,000 [CDRs]/60 [minutes]×0.31 [minutes]=9,375 [CDRs].

In this way, the time until real-time transfer becomes possible is (2)+(4)+(6)+(8)+α (approximately 20 seconds)=approximately 5 minutes. In other words, about 5 minutes after the recovery from the failure, the newly generated CDRs can be transferred in real time, and there is a high possibility that the CDRs generated within about 5 minutes will not be able to comply with the 3GPP restrictions. On the other hand, in the method according to the first embodiment, the new CDR and the saved CDR can be transmitted through separate connections, so transmission delay due to general protocols can be improved.

By the way, in the billing architecture, the CGF 30 may be made redundant by providing a primary (operation system) and a secondary (standby system) as the CGF 30 . In this case, by using the secondary CGF, which is a free resource that is not normally used, it is possible to improve the transmission delay due to the general protocol.

Therefore, in the second embodiment, transfer of saved CDRs will be described using a CGF redundancy system as an example. Here, CGF30 is used as the primary and CGF80 is used as the secondary, but the CGF80 is assumed to have the same functional configuration as the CGF30.

[Sequence diagram (communication failure)]
FIG. 14 is a sequence diagram illustrating the flow at the time of communication failure in the CGF redundant system according to the second embodiment; As shown in FIG. 14, assume that a communication failure occurs between the CDF 10 and each CGF (CGF 30, CGF 80) (S501), the failure is recovered (S502), and communication becomes possible.

Then, the CDF 10 transmits to the CGF 30 the Echo Request that was repeatedly retransmitted during the failure (S503 and S504). Upon recovery from the failure, the CGF 30 that has received this Echo Request responds with the Echo Request to the CDF 10 (S505 and S506).

Subsequently, the CDF 10 transmits a Data Record Transfer Request (empty packet) to the CGF 30 (S507 and S508). As a result, the normal GTP connection is re-established between the CDF 10 and the primary CGF 30, and the CDR generated after the failure is transmitted via the normal GTP connection (S509).

The CDF 10 transmits an Echo Request to the secondary CGF 80 in parallel with the above processing to the primary CGF 30 (S510 and S511). Upon recovery from the failure, the CGF 80 that has received this Echo Request responds with an Echo Response to the CDF 10 (S512 and S513).

Subsequently, the CDF 10 transmits a Data Record Transfer Request (empty packet) to the CGF 80 (S514 and S515). At that time, by setting the option IE Save CDR Information IE, the CGF is notified of the existence of the saved CDR.

Then, as a response to the Data Record Transfer Request, the CGF 80 transmits a Data Record Transfer Response, which is a request reception response, to the CDF 10 (S516 and S517). At this time, "Request Accepted" is set in Cause IE.

Thereafter, the CGF 80 transmits a save connection request to the CDF 10 (S518 and S519), and the CDF 10 transmits a response to the connection request to the CGF 80 (S520 and S521). As a result, a save GTP connection is established between the CDF 10 and the secondary CGF 80 (S522).

Subsequently, the CGF 860 transmits a Redirection Request to the CDF 10 (S523 and S524). At this time, the Cause IE of the message is set to "Saved CDR transfer Request" to request the CDF 10 to transfer the saved CDR.

The CDF 10 then transmits a Redirection Response to the CGF 80 as a response to the Redirection Request from the CGF 80 (S525 and S526). At this time, "Request Accepted" is set in Cause IE. The CDF 80 also manages sequence numbers for saving CDR transfer.

Thereafter, the CDF 10 transmits the saved CDR (saved CDR) to the CGF 80 via the GTP connection for saving (S527 and S528). At this time, the CDF 10 transmits a Data Record Transfer Request in which the Packet Transfer Command IE is set to "Send Data Record Packet" to the CGF 80, and transfers the CDR (saved CDR).

Thereafter, the CGF 80 stores the received CDR in the storage unit (S529), and transmits a Data Record Transfer Response as a reception response message to the CDF 10 (S530 and S531). At this time, "Request Accepted" is set in the Cause IE of the Data Record Transfer Response message.

Upon receiving the Data Record Transfer Response message, the CDF 10 deletes the transferred save CDR from the save DB 13 (S532). In this way, the saved CDR (saved CDR) is transferred to the secondary CGF 80 using the GTP connection for saving.

After that, when the CDF 10 sends the last saved CDR, it sets the Packet Transfer Command IE of the Data Record Transfer Request to "Last Send Data Record Packet" and notifies the CGF 80 of the end (S533 and S534).

Subsequently, the CGF 80 stores the received CDR in the storage unit (S535), and transmits a Data Record Transfer Response as a reception response message to the CDF 10 (S536 and S537). At this time, "Request Accepted" is set in the Cause IE of the Data Record Transfer Response message.

After that, the CDF 10 that received the Data Record Transfer Response message deletes the last saved CDR that has been transferred from the save DB 13 (S538). The CGF 80 then disconnects the GTP connection for saving and releases the resource (S539 and S540).

[Sequence diagram (system failure)]
FIG. 15 is a sequence diagram of the flow at the time of system failure in the CGF redundancy system according to the second embodiment; As shown in FIG. 15, it is assumed that a system failure occurs in the CGF 30 and communication between the CDF 10 and the CGF 30 is interrupted (S601 and S602), then the failure is restored (S603) and communication becomes possible.

Then, the CGF 30 transmits a Node Alive Request message to the CDF 10 (S604 and S605), and the CDF 10 transmits a Node Alive Response to the CGF 30 as a response (S606 and S607).

After that, the CDF 10 transmits a Data Record Transfer Request (empty packet) to the CGF 30 (S608 and S609). In this way, a normal GTP connection is re-established between the CDF 10 and the CGF 30, and transmission of the generated CDR after the failure is performed via the normal GTP connection (S610).

In parallel with the above processing to the primary CGF 30, the CGF 80 sends a Node Alive Request message to the CDF 10 (S611 and S612), and the CDF 10 sends a Node Alive Response to the CGF 30 as a response (S613 and S614). . Here, the CDF 10 notifies the CGF 80 of the existence of the save CDR by setting "Save CDR Information" in the Node Alive Response.

After that, GF80 transmits a connection request for saving to CDF10 (S615 and S616), and CDF10 transmits a response to the connection request to CGF80 (S617 and S618). As a result, the CGF 80 establishes a GTP connection for saving with the CDF 10 (S619). Note that the subsequent processing is the same as in FIG. 14, so detailed description is omitted.

In this way, by using the redundantly configured secondary CGF 80, it is possible to suppress an increase in the processing load on the primary CGF 30, minimize the impact of normal operations, and cause failures and processing delays in the CGF 30. can be suppressed. In the second embodiment, an example of establishing a GTP connection for saving between the CDF 10 and the primary CGF 80 has been described, but the present invention is not limited to this. For example, the GTP connection normally established between CDF10 and CGF80 for degeneration of CGF30 can be used to transfer the save CDR from CDF10 to CGF80.

By the way, the transfer of the saved CDR can also be executed at the maintenance person's timing. Therefore, in a third embodiment, an example will be described in which the maintenance terminal 90 used by the maintenance person takes the lead in executing various processes such as acquisition of the CDRs that have been saved. Here, taking a communication failure as an example, a system failure or a redundant configuration can be processed in the same way.

[Sequence diagram (communication failure)]
FIG. 16 is a sequence diagram illustrating a flow when a communication failure is initiated by a maintenance terminal according to the third embodiment; As shown in FIG. 16, assume that a communication failure occurs between the CDF 10 and the CGF 30 (S701), and then the failure is recovered (S702) and communication becomes possible.

Then, the CDF 10 transmits to the CGF 30 the Echo Request that was repeatedly retransmitted during the failure (S703 and S704). Upon recovery from the failure, the CGF 30 that has received this Echo Request responds with an Echo Response to the CDF 10 (S705 and S706).

Subsequently, the CDF 10 transmits a Data Record Transfer Request (empty packet) to the CGF 30 (S707 and S708). At this time, the CDF 10 notifies the CGF 30 of the existence of the save CDR by setting the option IE Save CDR Information IE. As a result, the normal GTP connection is reestablished between the CDF 10 and the CGF 30, and the CDR generated after the failure is transmitted via the normal GTP connection (S709).

After that, the maintenance terminal 90 transmits a request to collect the saved CDRs to the CGF 30 (S710 and S711). Upon receiving this request, the failure processing unit 60 of the CGF 30 transmits a save connection request to the CDF 10 (S712 and S713), and the CDF 10 transmits a response to the connection request to the CGF 30 (S714 and S715). As a result, the failure processing unit 60 of the CGF 30 establishes a GTP connection for saving with the CDF 10 (S716). The subsequent processing is the same as in FIG. 7 of the first embodiment, so detailed description is omitted.

After disconnecting the saving GTP connection and releasing the resources (S717 and S718), the failure processing unit 60 of the CGF 30 sends a save CDR collection end notification (normal) to the maintenance terminal 90 (S719 and S720). ).

[Sequence diagram (no backup CDR)]
FIG. 17 is a sequence diagram illustrating a flow of processing when there is no saved CDR at the initiative of the maintenance terminal according to the third embodiment; As shown in FIG. 17, it is assumed that the communication failure that occurred between the CDF 10 and the CGF 30 has been recovered and normal processing is being performed (S801).

After that, the maintenance terminal 90 transmits a request to collect the saved CDRs to the CGF 30 (S802 and S803). Upon receiving this request, the failure processing unit 60 of the CGF 30 transmits a save connection request to the CDF 10 (S804 and S805), and the CDF 10 transmits a response to the connection request to the CGF 30 (S806 and S807). As a result, the failure processing unit 60 of the CGF 30 establishes a GTP connection for saving with the CDF 10 (S808).

Subsequently, the failure processing unit 60 of the CGF 30 transmits Redirection Request to the CDF 10 (S809 and S810). At this time, the Cause IE of the message is set to "Saved CDR transfer Request" to request the CDF 10 to transfer the save CDR 30 .

Then, the failure processing unit 24 of the CDF 10 transmits a Redirection Response to the CGF 30 as a response to the Redirection Request from the CGF 30 (S811 and S812). At this time, since the backup CDR does not exist, the failure processing unit 24 sets "CDR does not exist" in the Cause IE. In addition to the existing items, "CDR does not exist" is newly added as a Redirection Response setting. The CGF 30 can detect that there is no backup CDR by setting this "CDR does not exist" in the Redirection Response.

As a result, the failure processing unit 60 of the CGF 30 disconnects the saving GTP connection to release the resources (S813 and S814), and sends a notification of completion of saving CDRs (no saving CDRs) to the maintenance terminal 90 (S815). and S816).

[Sequence diagram (deletion of backup CDR)]
FIG. 18 is a sequence diagram illustrating a flow of deletion of a saved CDR led by a maintenance terminal according to the third embodiment; As shown in FIG. 18, it is assumed that the communication failure that occurred between the CDF 10 and the CGF 30 has been recovered and normal processing is being performed (S901).

After that, the maintenance terminal 90 transmits a request to delete the saved CDR to the CGF 30 (S902 and S903). Upon receiving this request, the failure processing unit 60 of the CGF 30 transmits a save connection request to the CDF 10 (S904 and S905), and the CDF 10 transmits a response to the connection request to the CGF 30 (S906 and S907). As a result, the failure processing unit 60 of the CGF 30 establishes a GTP connection for saving with the CDF 10 (S908).

Subsequently, the failure processing unit 60 of the CGF 30 transmits Redirection Request to the CDF 10 (S909 and S910). At this time, "Saved CDR delete request" is set in the Cause IE of the message, and the CDF 10 is requested to delete the save CDR 30 . As shown in FIG. 9, as a setting of Redirection Request, "Saved CDR delete request" is newly added in addition to the existing items such as Address of Recommended Node. The CDF 10 can detect the save CDR deletion request by setting this "Saved CDR delete request" in the Redirection Request.

Since "Saved CDR delete request" is set in the Redirection Request from the CGF 30, the failure processing unit 24 of the CDF 10 deletes the saved CDR saved in the save DB 13 without transmitting it to the CGF 30 ( S911).

After that, the failure processing unit 24 of the CDF 10 transmits a Redirection Response in which "Request Accepted" is set to the CGF 30 (S912 and S913). Then, the failure processing unit 60 of the CGF 30 disconnects the GTP connection for saving to release the resource (S914 and S915), and transmits a notification of completion of deletion of the saving CDR (normal) to the maintenance terminal 90 (S916 and S917). .

[effect]
As described above, by collecting Evacuated CDRs under the initiative of CGF30, it is possible to provide services such as acquisition and deletion of Evacuated CDRs. can be selected. In addition, by providing flexible support, versatility is improved, and the spread of the system can be expected.

By the way, it is also conceivable that a new failure occurs during transmission of the saved CDRs after recovery from the failure, resulting in a saved CDR transmission error. Therefore, in a fourth embodiment, an example of how to deal with a save CDR transmission error will be described.

[sending error]
FIG. 19 is a sequence diagram illustrating a flow when a transmission error occurs after failure recovery according to the fourth embodiment; As shown in FIG. 19, the processing from S1001 to S1014 is the same as the processing from S310 to S314 in FIG. 7, so detailed description will be omitted.

When the GTP connection for saving is established, the failure processing unit 60 of the CGF 30 transmits a Redirection Request with "Saved CDR transfer request" set to the CDF 10 (S1015 and S1016).

Then, the CDF 10 transmits a Redirection Response in which "Request Accepted" is set as a response to the Redirection Request from the CGF 30 to the failure processing unit 60 of the CGF 30 (S1017 and S1018).

After that, the CDF 10 sets "Send Data Record Packet" in the Data Record Transfer Request corresponding to the save CDR with sequential number 1 (Seq: 1), and transmits it to the failure processing unit 60 via the save GTP connection. (S1019 and S1020). However, a communication failure occurs during the transfer, and the failure processing unit 60 of the CGF 30 cannot receive the saved CDR with the sequential number 1. Therefore, the failure processing unit 60 of the CGF 30 cannot transmit the Data Record Transfer Response, which is a response, to the CDF 10 .

Then, when the failure is restored (S1021), the CDF 10 does not receive a reception response to the Data Record Transfer Request with the sequential number 1 (Seq: 1), so the sequential number 1 ( The saved CDR (Data Record Transfer Request) of Seq: 1) is sent again to the failure processing unit 60 of the CGF 30 (S1022 and S1023). "Send Data Record Packet" is also set in the Data Record Transfer Request at this time.

After that, the failure processing unit 60 of the CGF 30 stores the saved CDR of the received sequential number 1 in the CDR storage DB 33 of the storage unit 32 (S1024 and S1025), and transmits a Data Record Transfer Response as a reception response message to the CDF 10 ( S1026 and S1027).

After receiving the Data Record Transfer Response message, the CDF 10 deletes the saved CDR with the sequential number 1, which has already been transferred, from the save DB 13 (S1028). In this way, transfer of the saved CDR (saved CDR) is executed using the GTP connection for saving. Subsequent transmission processing for sequential numbers 2 and later is the same as S319 to S334 in FIG. 7, so detailed description thereof is omitted.

[Response error]
FIG. 20 is a sequence diagram illustrating the flow when a response error occurs after failure recovery according to the fourth embodiment. As shown in FIG. 20, the processing from S2001 to S2014 is the same as the processing from S310 to S314 in FIG. 7, so detailed description will be omitted.

When the GTP connection for saving is established, the failure processing unit 60 of the CGF 30 transmits a Redirection Request in which "Saved CDR transfer request" is set to the CDF 10 (S2015 and S2016).

Then, the CDF 10 transmits a Redirection Response in which "Request Accepted" is set as a response to the Redirection Request from the CGF 30 to the failure processing unit 60 of the CGF 30 (S2017 and S2018).

After that, the CDF 10 sets "Send Data Record Packet" in the Data Record Transfer Request corresponding to the save CDR with sequential number 1 (Seq: 1), and transmits it to the failure processing unit 60 via the save GTP connection. (S2019 and S2020).

Subsequently, the failure processing unit 60 of the CGF 30 stores the received CDR in the CDR storage DB 33 of the storage unit 32 (S2021 and S2022), and sends a Data Record Transfer Response with "Request Accepted" set to the CDF 10 as a reception response message. (S2023 and 2024). However, a communication failure occurs during the transfer, and the CDF 10 cannot receive the Data Record Transfer Response.

Then, when the failure is restored (S2025), the CDF 10 does not receive a reception response to the Data Record Transfer Request with the sequential number 1 (Seq: 1), so the sequential number 1 ( The CDR (Data Record Transfer Request) of Seq: 1) is sent again to the failure processing unit 60 of the CGF 30 (S2026 and S2027). "Send Data Record Packet" is also set in the Data Record Transfer Request at this time.

After that, the failure processing unit 60 of the CGF 30 discards the saved CDR of the received sequential number 1 since it has already been received (S2028), and sends the received response message Data Record Transfer Response with "Request already fulfilled" set. is sent to the CDF 10 (S2029 and S2030).

Subsequent transmission processing for sequential numbers 2 and later is the same as S319 to S334 in FIG. 7, so detailed description thereof is omitted.

[Transmission error on last CDR]
FIG. 21 is a sequence diagram illustrating the flow when an error occurs at the end of saving CDR according to the fourth embodiment. As shown in FIG. 21, processing from S3001 to S3011, which is processing from occurrence of a failure to transfer of the last saved CDR, is the same as processing from S301 to S325 in FIG. 7, so detailed description thereof will be omitted.

After that, the CDF 10 sets the save CDR of (Seq: Last), which is the last CDR, to the Data Record Transfer Request corresponding to the save CDR to "Last Send Data Record Packet", and via the GTP connection for saving, It is transmitted to the failure processing unit 60 (S3012 and S3013).

Subsequently, the failure processing unit 60 of the CGF 30 stores the received final saved CDR in the CDR storage DB 33 of the storage unit 32 (S3014 and S3015). At this point, the failure processing unit 60 of the CGF 30 releases the saved CDR instance data (sequence number, etc.).

Then, the failure processing unit 60 of the CGF 30 transmits a Data Record Transfer Response in which "Request Accepted" is set as a reception response message to the CDF 10 (S3016 and S3017). However, a communication failure occurs during the transfer, and the CDF 10 cannot receive the Data Record Transfer Response.

Then, when the failure is restored (S3018), the CDF 10 does not receive the reception response of the Data Record Transfer Request with the sequential number (Seq: Lat), so the sequential number (Seq: Last) CDR (Data Record Transfer Request) to the failure processing unit 60 of the CGF 30 again (S3019 and S3020). "Last Send Data Record Packet" is also set in the Data Record Transfer Request at this time.

After that, the failure processing unit 60 of the CGF 30 discards the saved CDR of the received sequential number 1 since it has already been received (S3021). Then, since the instance data for saving CDR has already been released, the failure processing unit 60 of the CGF 30 transmits a Data Record Transfer Response in which "Instance data already released" is set to the CDF 10 as a reception response message (S3022). and S3023). As shown in FIG. 10, four pieces of information such as 1 (Send Data Record Packet) can be specified in the "Packet Transfer Command IE" of the Data Record Transfer Request, but a new item "Instance data already set "released".

After that, the CDF 10 that received the Data Record Transfer Response message deletes the last saved CDR that has been transferred from the save DB 13 (S3024). Then, the failure processing unit 60 of the CGF 30 disconnects the GTP connection for saving and releases the resource (S3025 and S3026). It should be noted that, before S3025, transfer processing is executed in the same manner as in the first embodiment for the save CDR newly generated during the occurrence of the failure from S3017 to S3018.

[effect]
As described above, even if an error occurs in the save CDR transmission process, the save error can be sent without delay regardless of the timing of the error, and the sequential number will be observed and sent. be able to.

Although the embodiments of the present invention have been described so far, the present invention may be implemented in various different forms other than the embodiments described above.

[Specify response instructions]
In the above embodiment, an example was explained in which deletion of the saved CDR was specified, but the present invention is not limited to this. For example, it is possible to specify various correspondence instructions, such as specifying the acquisition start time of the saved CDR, specifying the transfer destination CGF when there are multiple CGFs, and the like.

[CGF redundancy]
For example, when the CGF is redundant, we explained an example of using the CGF of the standby system to acquire the save CDR, but instead of the GTP connection for saving, it is also possible to use the GTP connection for degeneracy. can. In this case, the CGF of the standby system can suppress the establishment of the connection for saving after the recovery from the failure, and restore only the GTP connection for degeneration that is normally established.

[system]
Information including processing procedures, control procedures, specific names, and various data and parameters shown in the above documents and drawings can be arbitrarily changed unless otherwise specified. Further, the specific examples, distributions, numerical values, etc. described in the examples are merely examples, and can be arbitrarily changed.

Also, each component of each device illustrated is functionally conceptual, and does not necessarily need to be physically configured as illustrated. That is, the specific forms of distribution and integration of each device are not limited to those shown in the drawings. That is, all or part of them can be functionally or physically distributed and integrated in arbitrary units according to various loads and usage conditions. Further, each processing function performed by each device may be implemented in whole or in part by a CPU and a program analyzed and executed by the CPU, or implemented as hardware based on wired logic.

[hardware]
FIG. 22 is a diagram illustrating a hardware configuration example. Since the CDF 10 and the CGF 30 have the same configuration, they will be described as an information processing device 100 here. As shown in FIG. 22, the information processing device 100 has a communication device 10a, a HDD (Hard Disk Drive) 10b, a memory 10c, and a processor 10d. 22 are interconnected by a bus or the like.

The communication device 10a is a network interface card or the like, and communicates with other servers. The HDD 10b stores programs and DBs for operating the functions shown in FIG.

The processor 10d reads from the HDD 10b or the like a program for executing processing similar to that of each processing unit shown in FIG. 2 and develops it in the memory 10c, thereby operating processes for executing each function described with reference to FIG. 3 and the like. For example, taking the CDF 10 as an example, this process executes functions similar to those of the processing units of the CDF 10 . Specifically, the processor 10d reads a program having functions similar to those of the event reception unit 21, the CDR generation unit 22, the CDR transmission unit 23, the failure processing unit 24, and the like, from the HDD 10b and the like. Then, the processor 10d executes processes for executing processes similar to those of the event reception unit 21, the CDR generation unit 22, the CDR transmission unit 23, the failure processing unit 24, and the like.

As described above, the information processing apparatus 100 operates as an information processing apparatus that executes a control method by reading and executing a program. Further, the information processing apparatus 100 can read the program from the recording medium using the medium reading device and execute the read program, thereby realizing the same functions as those of the above-described embodiments. Note that the programs referred to in other embodiments are not limited to being executed by the information processing apparatus 100 . For example, the present invention can be applied in the same way when another computer or server executes the program, or when they cooperate to execute the program.

This program can be distributed via a network such as the Internet. Also, this program is recorded on a computer-readable recording medium such as a hard disk, flexible disk (FD), CD-ROM, MO (Magneto-Optical disk), DVD (Digital Versatile Disc), etc., and is read from the recording medium by a computer. It can be executed by being read.

10 CDFs
11 Communication Unit 12 Storage Unit 13 Saving DB
20 control unit 21 event reception unit 22 CDR generation unit 23 CDR transmission unit 24 failure processing unit 25 CDR saving unit 26 failure handling unit 30 CGF
31 communication unit 32 storage unit 33 CDR storage DB
40 control unit 50 normal processing unit 51 CDR reception unit 52 CDR processing unit 60 failure processing unit 61 protocol control unit 62 CDR support unit

Claims (8)

a receiving unit that receives the billing information via a first connection established with a billing generation device that generates billing information used for billing communication charges;
an establishing unit that establishes the first connection and the second connection with the charge generation device when communication with the charge generation device is restored after communication with the charge generation device is interrupted; ,
receiving, via the first connection, first billing information generated after the communication is restored, and receiving, via the second connection, second billing information generated during the disconnection of the communication; A control device comprising: a reception control unit that acquires billing information. 2. The apparatus according to claim 1, wherein said establishing unit disconnects said second connection while maintaining establishment of said first connection when acquisition of said second billing information is completed. Control device. 2. The method according to claim 1, wherein said reception control unit transmits a request including a corresponding instruction regarding acquisition or deletion of said second billing information to said billing generation device via said second connection. Control device as described. The control device is a standby control device among a plurality of redundant control devices,
The establishing unit establishes a second connection for evacuation with the charge generation device after communication between the plurality of control devices and the charge generation device is interrupted and restored, and
2. The control device according to claim 1, wherein the reception control unit acquires the second billing information via the second connection for saving . The establishing unit establishes the first connection and the second connection using a GPRS (General Packet Radio Service) tunneling protocol used in an offline charging architecture of a 3GPP (Third Generation Partnership Project) network. 2. Control device according to claim 1. the computer
receiving the billing information via a first connection established with a billing generation device that generates billing information used for billing communication charges;
establishing the first connection and the second connection with the charge generation device when communication with the charge generation device is restored after communication with the charge generation device is interrupted;
receiving, via the first connection, first billing information generated after the communication is restored, and receiving, via the second connection, second billing information generated during the disconnection of the communication; A charge acquisition method characterized by executing a process of acquiring charge information. to the computer,
receiving the billing information via a first connection established with a billing generation device that generates billing information used for billing communication charges;
establishing the first connection and the second connection with the charge generation device when communication with the charge generation device is restored after communication with the charge generation device is interrupted;
receiving, via the first connection, first billing information generated after the communication is restored, and receiving, via the second connection, second billing information generated during the disconnection of the communication; A charge acquisition program characterized by executing a process of acquiring charge information. In a billing system including a billing generation device and a control device,
The billing generation device
a generation unit that generates billing information used for billing communication charges;
a transmission unit configured to transmit the billing information via a first connection established with the control device;
The control device is
a receiving unit that receives the billing information via the first connection established with the billing generation device;
an establishing unit that establishes the first connection and the second connection with the charge generation device when communication with the charge generation device is restored after communication with the charge generation device is interrupted; ,
receiving, via the first connection, first billing information generated after the communication is restored, and receiving, via the second connection, second billing information generated during the disconnection of the communication; A billing system, comprising: a reception control unit that acquires billing information.

Images