KR20060006148A - Method and system for handling wcdma packet cdr - Google Patents

Abstract

The present invention provides a shared memory for storing billing data, raw billing data received from at least one billing data generating device and complete billing data generated in a shared memory, and control information corresponding to billing data stored in the shared memory. WCDMA packet charging data processing method comprising an application layer to generate, and temporarily stores the received control information, and transmits the received control information to any application process included in the application layer (MX BUS) and System, a universal function of routing data to an appropriate process according to the type and nature of each CDR in a multi-process environment that handles billing information generated in a Universal Mobile Telecommunications System (UMTS) Packet Switched Core Network (PS-CN) To provide.

Billing, WCDMA, control, telecommunications,

Description

Method and system for handling WCDMA packet CDR             

1 is a block diagram schematically illustrating a configuration of a general Universal Mobile Telecommunication Systems (UMTS) Packet Switched Core Network (PS-CN) including a charging gateway.

2 is a diagram illustrating a process configuration of a conventional charging gateway.

3 is a view showing a data processing procedure in a conventional mediation module.

Figure 4 is a block diagram of an MX BUS according to an embodiment of the present invention.

5 illustrates a message ID format according to a preferred embodiment of the present invention.

Figure 6 illustrates a shared memory structure in accordance with one preferred embodiment of the present invention.

7 is a data flow diagram illustrating a connection establishment process between an application process and an MX BUS according to an embodiment of the present invention.

8 is a data flow diagram illustrating a connection release process between the application processes and the MX BUS according to an embodiment of the present invention.

9 is a diagram illustrating a process of recovering an error generated in a data writing process according to an exemplary embodiment of the present invention.

FIG. 10 is a diagram illustrating a process of recovering an error generated in a process of reading and writing data according to an exemplary embodiment of the present invention. FIG.

11 is a diagram illustrating a process of recovering an error generated in a data reading process according to an exemplary embodiment of the present invention.

12 is a diagram illustrating an error recovery process when restarting after the termination of the MX BUS according to an embodiment of the present invention.

13 is a view showing a load sharing process according to an embodiment of the present invention.

The present invention relates to a WCDMA packet billing data processing method and system, and more particularly to routing to the appropriate process according to the type (type) and characteristics of each billing data (CDR: Call Detail Record or Charging Data Record) collected in a multi-process environment The present invention relates to a method and system for processing WCDMA packet charging data that provides a general purpose function.

FIG. 1 is a block diagram schematically illustrating a configuration of a general Universal Mobile Telecommunication Systems (UMTS) packet switched core network (PS-CN) including a charging gateway. .

Referring to FIG. 1, a universal mobile communication service system (UMTS) includes a base station 115, a Radio Network Controller (RNC) 120, a Serving GPRS Supporting Node (SGSN) 125, and an HLR. (Home Location Register) 130, Gateway GPRS Supporting Node (GGSN) (135), Charging Gateway (CG) 140, and Billing System (BS) (145) ). In addition, the universal mobile communication system (UMTS) may further include various components.

The SGSN 125 performs subscriber authentication and mobility management, and the GGSN 135 performs a connection between the UMTS PS-CN and an external data network. The SGSN 125 and the GGSN 135 are main network elements for call control in a UMTS packet switched network.

The CG 140 collects and processes the charging information from the SGSN 125 and the GGSN 135 and transmits the charging information to the BS 145. That is, the CG 140 receives a GSNN-Call Detail Record (G-CDR) including charging information according to the use of an external data network such as the Internet from the GGSN 135, and receives an internal network from the SGSN 125. Receive SSGSN-Call Detail Record (S-CDR) including billing information about usage. In addition, the CG 140 includes an S-SMO-CDR including charging information regarding a mobility-call detail record (M-CDR) and a short message service (SMS) including charging information regarding mobility management. And S-SMT-CDR.

CG 140 buffers the received billing information, decodes by Basic Encoding Rules (BER), aggregates for partial CDRs, and formats into formats requested by BS 145. Performs reformatting functions.

2 is a diagram illustrating a process configuration of a conventional charging gateway.

Referring to FIG. 2, the CG 140 includes an application layer 205 and an infrastructure layer 210.

The application layer 205 includes three main modules: a collection module, a mediation module, and a distribution module. The collecting module collects charging data, the mediation module processes the collected charging data, and the distribution module distributes the processed charging data to a target system.

Infrastructure layer 210 provides basic functions for modules that make up an application layer and an Operation & Management (O & M) layer (not shown).

The interaction of the components included in the application layer 205 and the infrastructure layer 210 will now be described in detail.

CG 140 receives charging information from GGSN 135 and SGSN 125 using GPRS Tunneling Protocol Prime (hereinafter referred to as “Ga”) as a standard interface. Ga standard is defined in 3GPP TS-32.215, and within this standard, message format, information element (IE) format, duplication protection mechanism, backup in case of data transmission are required. (back-up) redirection to equipment.

The Ga receiver (charging information collecting unit 215) in the collecting module receives and stores the charging information from the SGSN 125 and the GGSN 135. The stored billing information can be used for buffering for future recovery and verification. The Ga receiver 215 also transmits the received charging information to the MX BUS 240.

The adapter 220 of the mediation module performs BER decoding on the charging information read from the MX BUS 240. This is because the charging information received through the Ga receiver 215 is encoded by the Basic Encoding Rule (BER) of ASN.1 (Abstract Syntax Notation. 1). At this time, the integrity of the data for each field is determined to perform a fraud detection function, and the decoding result is written to the MX BUS 240. A data routing path is established by combining fields that are routing keys among CDR fields, and a data collection function is performed using user information and an address as keys.

In case of G-CDR and S-CDR, the occurrence of events such as data volume, duration time limit, QoS change, rate time change, etc. Since partial CDRs are generated, a process of aggregating them into one CDR is required.

Aggregator 225 performs a function of integrating the received incomplete CDR into one CDR, and releases when the last CDR related to the session is received.

The integrated CDR can be sent to any BS 145. However, when there are a plurality of BSs, the charging information required by each BS 145 may be different.

Collector 230 performs a function of filtering the data necessary to meet this demand, the filtered charging information is distributed to each BS 145 through a distribution module.

In addition, the regulator 235 of the distribution module may perform a function of filing a CDR processed in an event unit.

3 is a diagram illustrating a data processing process in a conventional mediation module.

As shown in FIG. 3, the adapter 220 collects the MX BUS 240 when there is an incomplete CDR among the G-CDR and S-CDR collected by the Ga receiver 215 and recorded in the MX BUS 240. The defective CDR is routed to the Aggregator 225. Incomplete CDRs are not present or other types of CDRs are not sent directly to Collector 230 via MX BUS 240 because no integration process is required.

Since the hot-bill CDRs among the CDRs filtered by the collector 230 should be immediately transmitted to the BS 145, the hot-bill CDRs are routed to the first regulator 310, which is a process of processing in record units, and is normal. ) CDR routes to the second regulator 320, which bundles several records and processes them into a single file.

As such, the components in the application layer of the conventional charging gateway read data to process the charging information generated in the UMTS PS-CN, undergo unique processing, and then process the data for a post procedure. To the MX BUS 240.

However, such a conventional billing data processing method has a problem in that it is not possible to guarantee a transaction in process when a large amount of data is to be processed, or an error occurs in the process.

Accordingly, an object of the present invention for solving the above problems is to provide data according to the type and characteristics of each CDR in a multi-process environment for processing charging information generated in a Universal Mobile Telecommunications System (UMTS) packet switched core network (PS-CN). To provide a method and system for processing WCDMA packet charging data that provides a universal function of routing a to an appropriate process.

It is another object of the present invention to provide a method and system for processing WCDMA packet charging data in which components included in the charging gateway adopt the same data routing scheme to facilitate system development.                         

It is still another object of the present invention to provide a WCDMA packet charging data processing method and system that can easily change the routing path of charging information only by updating control information in the case of adding a charging CDR.

It is still another object of the present invention to provide a method and system for processing WCDMA packet charging data, which can route only control information when charging data is mediated or integrated, and actual charging data is stored in a shared memory to maintain improved performance even when processing a large amount of data. It is.

It is still another object of the present invention to provide a method and system for processing WCDMA packet charging data, which adopts a shared memory structure suitable for CDR processing, enables data processing of variable length, and facilitates allocation and release of shared memory resources.

It is still another object of the present invention to maintain continuity with respect to data processing upon restarting after termination (normal termination or abnormal termination) of each component of the billing gateway, thereby preventing duplication or loss of charging information. It is to provide a data processing method and system.

Another object of the present invention is a method and system for processing WCDMA packet charging data that can support a non-blocking mode to enable load sharing and distributed processing, thereby preventing bottlenecks even under load concentration. To provide.

In order to achieve the above objects, according to an aspect of the present invention, in the apparatus for processing packet billing data, a shared memory for storing billing data, wherein the billing data is raw billing data, partial billing data And full charging data; Receive raw billing data from at least one billing data generating device and store it in the shared memory, generate the full billing data using the raw billing data, store the full billing data in the shared memory, the shared memory An application layer for generating control information corresponding to the charging data stored in the mobile terminal, and transferring the complete charging data to a billing system, wherein the control information includes a MID for verifying the control information; Storage location information, including routing destination information; And an MX bus for receiving and temporarily storing the control information and transferring the received control information to any application process included in the application layer, wherein the charging data is stored in the shared memory. An area to be stored is provided at the time of startup of the MX bus, and the designated shared memory area is individually allocated to a plurality of application processes included in the application layer.

 The application layer includes a plurality of application processes; MX Application Process Interface (MX API), which provides a method for the application process to interact with the MX bus, wherein the method is Open () for connection connection between the application layer and the MX bus. , At least one of Close () for disconnection, Read () for reading data, and Write () for writing data; A memory manager (DP Handler Class) for managing an individual shared memory area allocated corresponding to each of the application processes, and storing the charging data by an arbitrary application process in the individual shared memory area; And transfer the control information generated by any application process storing the charging data in the respective shared memory area to the MX bus, receive the control information from the MX bus, and transfer the control information to a corresponding application process. It can include a Message Queue Class. The plurality of application processes may include: a billing data receiver configured to receive the raw billing data from the billing data generating device and store the raw billing data in the shared memory; A decoder for decoding the raw billing data and storing it in the shared memory; An aggregator for integrating incomplete charging data into one full charging data when incomplete charging data is present among the decoded raw charging data, and storing the integrated complete charging data in the shared memory; A collector for converting the complete billing data into a predetermined form for processing in the billing system; And a transfer unit for transferring the charging data converted by the collection unit to the charging system.

The MX bus transmits a subsequent processing request to the integrating unit or the collecting unit by using routing destination information included in the control information received from the decoding unit, and each application process is connected to the control information received from the MX bus. Correspondingly, the predetermined data processing is performed using the charging data stored in the shared memory.

When a connection connection request is received from the MX application process interface, the MX bus temporarily stores charging data being processed by the plurality of application processes and control information corresponding to the charging data, and the application processes After generating a message queue for transmitting and receiving control information, and designating the shared memory area, and generating a message I / O for routing any control information, the M-X application The connection connection response is performed by transmitting a connection connection response to each application process through the process interface, wherein the connection connection response includes an individual shared memory area address and a message queue ID allocated to the application process.

 The shared memory is allocated in units of pages of a predetermined size, at least one data page header block, at least one data page start block dependent on one data page header block. And one or more Data Page Continuous Blocks subordinate to one data page start block, wherein the data page header blocks are allocated one for each application process and stored corresponding to the data page header blocks. The data page start block indicates the first page where each application process can record charging data, and the data page continuous block has one page having a length of the charging data. Variable-length if greater than or equal to Characterized in that the dynamically allocated to process the data.

 When the use information of the data page header block indicates unused information, the storage area corresponding to the data page header block is dynamically allocated to another application process.

The billing data stored in the data page start block and the data page contiguous block are deleted when a corresponding subsequent application process reads and processes the billing data, and usage information is set to unused.

The MID may include packet charging data processing device identification information, application process identification information, and sequence information corresponding to a processing order of an application process corresponding to the application process identification information.

The billing data receiver temporarily stores the MID of the finally processed control information, and if the billing data receiver is restarted after abnormal termination, the billing data receiver sends the MID to the Mx bus and the Mx bus If the MID received from the billing data receiving unit is inconsistent with the temporarily stored processing completed MID, characterized in that for transmitting the billing data processing request corresponding to the MID to the billing data receiving unit.

When the MX bus receives a read request for arbitrary raw charging data from the decoding unit, the MX bus transmits control information about the raw charging data to the decoding unit, and MID corresponding to the transmitted control information. And temporarily restart the decoding unit after abnormal termination, and retransmit control information corresponding to the stored MID to the decoding unit.

When the transfer unit is restarted after abnormal termination, the transfer unit transmits the MID of control information corresponding to the final charging data transmitted to the charging system to the MX bus, and the MX bus is temporarily received from the one or more stored MIDs. The MID matching the MID is deleted, and control information corresponding to the remaining MID is transmitted to the transfer unit.

According to another aspect of the present invention, a method for processing packet charging data in a packet charging processing apparatus including an application layer, an MX bus and a shared memory, wherein the application layer is a billing data receiver (Ga Receiver), decoding. And a plurality of application processes corresponding to an adapter, an aggregator, a collector, and a regulator, wherein the charging data receiver is configured to receive the raw charging data from the charging data generating device. After receiving and storing in the shared memory, generating the first control information corresponding to the stored raw billing data to pass to the M-bus, where the control information is MID for verifying the control information, the Storage location information of charging data, routing destination information; The MX bus transferring the first control information to the decoding unit for subsequent processing of the raw charging data; The decoding unit reads, decodes and stores the raw charging data corresponding to the first control information in the shared memory, generates second control information corresponding to the stored decoded raw charging data, and transfers the generated control data to the MX bus. Doing; Transmitting, by the MX bus, the second control information to the collection unit when the decoded raw charging data is full charging data; The collection unit reads the complete billing data corresponding to the second control information, converts it into a form that can be processed by a billing system, stores it in the shared memory, and generates corresponding third control information. Transferring to the MX bus; Transmitting, by the MX bus, the third control information to the transfer unit; And the transfer unit reading the converted charging data corresponding to the third control information from the shared memory and delivering the converted charging data to the charging system, wherein the region where the charging data is stored in the shared memory is the MX bus. Is designated at start-up time, and the designated shared memory area is individually allocated to a plurality of application processes included in the application layer.

The packet charging data processing method may further include: transmitting, by the MX bus, the fourth control information to the integrating unit when partial charging data exists among the decoded raw charging data; And integrating, by the integrator, a plurality of incomplete charging data to store integrated complete charging data in the shared memory, and then generating fourth control information corresponding to the complete charging data and transmitting the fourth control information to the MX bus. It may include.

The packet charging data processing method may further include: receiving, by the MX bus, a connection connection request from the application layer; The MX bus performing a connection connection; And transmitting a connection connection response to the application layer. In this case, the MX bus temporarily stores charging data being processed by the plurality of application processes and control information corresponding to the charging data, and a message queue for transmitting and receiving control information with the application processes. Generate a message, specify a shared memory area, and generate a message input / output unit (Message I / O) for routing arbitrary control information to perform a connection connection, and the connection connection response is allocated to the application process. It can include individual shared memory area addresses and message queue IDs.

The shared memory is allocated in units of pages of a predetermined size, at least one data page header block, at least one data page start block dependent on one data page header block. And one or more Data Page Continuous Blocks subordinate to one data page start block, wherein the data page header blocks are allocated one for each application process and stored corresponding to the data page header blocks. The data page start block indicates the first page on which each application process can record charging data, and the data page continuous block has one page having a length of the charging data. Variable-length if greater than or equal to Characterized in that the dynamically allocated to process the data.

 When information on whether the data page header block is used indicates unused information, a storage area corresponding to the data page header block may be dynamically allocated to another application process.

The MID may include packet charging data processing device identification information, application process identification information, and sequence information corresponding to a processing order of an application process corresponding to the application process identification information.

The packet charging data processing method includes temporarily storing a MID of control information finally processed by the charging data receiving unit; Transmitting, by the charging data receiver, the MID to the MBUS when the charging data receiver is restarted after abnormally terminating; Determining, by the MX bus, whether the MID received from the charging data receiver matches the processed MID temporarily stored in the MX bus; And in case of inconsistency, transmitting a processing request for charging data corresponding to the MID to the charging data receiver.

The packet charging data processing method may include: transmitting, by the MX bus, the first control information to the decoding unit when a read request for any raw charging data is received from the decoding unit; The MX bus temporarily storing a MID corresponding to the transmitted control information; Determining, by the MX bus, whether the decoding unit has been restarted after abnormal termination; And re-transmitting control information corresponding to the stored MID to the decoding unit when restarted after abnormal termination.

The packet charging data processing method may include: when the transmission unit is restarted after abnormal termination, transmitting the MID of control information corresponding to the complete charging data finally transmitted to the charging system to the MX bus; Detecting an MID that matches the received MID from one or more MIDs temporarily stored in the MX bus; And if there is a matching MID, transmitting control information corresponding to the remaining non-matching MID to the transfer unit.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, the same reference numerals will be used for the same means regardless of the reference numerals in order to facilitate the overall understanding.

4 is a block diagram of an MX BUS according to a preferred embodiment of the present invention, FIG. 5 is a diagram illustrating a message ID format according to a preferred embodiment of the present invention, and FIG. 6 is a preferred embodiment of the present invention. A diagram illustrating a shared memory structure according to an example.

4, the MX BUS 400 of the Charging Gateway (CG) according to the present invention is a message queue class (Message Queue Class, 430b-hereinafter referred to as 'Msg Queue Class'), the message input and output unit ( Message Input / Output, 440-below, referred to as' Msg I / O ', Class Queue (Class Queue, 445-below, referred to as' Class Queue'), Message Router, 450-below, 'Msg Router "Connection Manager", Connection Manager (455-hereinafter referred to as "Connection Mgr"), Monitoring (Statistics monitor, 460-referred to as "Statistics monitor"), MID Location Manager (MID Location Manager, 465) Hereinafter referred to as 'MID Location Mgr', a MID manager (MID Manager, 470 hereinafter, referred to as 'MID Mgr') and a settlement unit (Audit, 475-hereinafter referred to as 'Audit').

Msg Queue Class (430b) is after each application process (AP: Access Process, 410) of the application layer of the CG 140, using the shared memory operating unit (DP Handler Class, 420) to record the charge CDR in the shared memory In the case of writing to the Message Queue 435 through the Msg Queue class 430a, control information recorded in the Message Queue 435 is received.

The Msg I / O 440 is created in the form of a thread when each application process requests a session connection. The Msg I / O 440 reads control information from the Msg Queue class 430b and processes it. The processing type of Msg I / O 440 includes 'Write' (the destination is determined using the corresponding control information, and then the control information is temporarily stored in the destination class queue), and 'Read' (Msg Queue Class ( 430b) retrieves the control information (pop) and writes it to the Message Queue (435) so that the application process can read the corresponding data), 'Read Write' (Read and Write as a transaction) Bundle processing), 'TrStart, TrWrite, TrStop' (bundling multiple data into a single transaction).

The class queue 445 is a repository for providing control information to each application process 410. When an arbitrary application process terminates the data processing process and requests reading of new data, the MX BUS 400 class. The corresponding control information is retrieved from the queue 445 and popped to the corresponding application process.

The Msg Router 450 determines the destination using the source application ID and the branch condition information in the read control information.

The Connection Mgr 455 is created in the form of a thread when the MX BUS 400 is initialized and processes a session connection request and a session termination request of an application layer through a UDP socket. When a session connection request is received from the application layer, the Connection Mgr 455 checks whether the request is a duplicate request, performs a recovery function on previously incomplete data, and executes various resources (for example, sharing). Create memory, Message Queue, Class Queue, etc.)

The statistics monitor 460 is created in the form of a thread when the MX BUS 400 is initialized. The statistics monitor 460 monitors the quantity of data queued in each class queue to identify the current processing state and the bottleneck.

The MID Location Mgr 465 stores the location of the data stored in the shared memory 425 in the form of a map, and manages the storage location of the corresponding message using MID (Message ID) as a key. The MID is assigned by the DP Handler Class 420. That is, the DP Handler Class 420 is a class that manages shared memory. The DP handler class 420 allocates a shared memory area to be used by each application process, and records the data processed by each application process in a free block of the shared memory. Each application process assigns a MID to the data to be processed. Hereinafter, a message ID (MID) for proving a corresponding transaction when the MX BUS 400 exchanges data with each application process will be described with reference to FIG. 5. The CG 140 according to the present invention stores the actual data processed by each application process in the shared memory 425 in order to improve data routing efficiency, and does not route separately. Therefore, only control information related to the MX BUS 400 needs to be routed. The control information includes a MID for identifying the message, an address of the shared memory 425 in which the data is stored, a data length, a source application process ID which generated the data, and a path define flag for determining a routing destination. ), And the like. Among these, the MID is a package ID field 510, a process ID field 520, and a message so that multiple application processes that play the same role for load sharing are not duplicated when they are simultaneously started. A message sequence field 530 is included. The package ID field 510 is for specifying one CG 140 when there are a plurality of charging gateways in the same home network. The process ID field 520 is for specifying one application process among a plurality of application processes existing in the application layer of the CG 140. The message number field 530 is information sequentially assigned to a message processed in a specific application process.

The MID Mgr 470 temporarily stores the MID of the data in which each application process is performing a transaction, so that the corresponding data may be recovered when restarting after abnormal termination of each application process.

Audit 475 is used for recovery when MX BUS 400 is restarted after abnormal termination. That is, all data in progress of the current transaction are stored in the audit file 480. When the MX BUS 400 is restarted after abnormal termination, the data is read from the corresponding audit file 480 and used for recovery.

In addition, further describing the external components shown in FIG. 4, the MX API 415 provides a method for each application process to interact with the MX BUS 400. The methods provided by the MX API (415) include 'MxOpen' (used to establish a connection with MX BUS (400)), 'MxClose' (used to disconnect from MX BUS (400)), and 'MxRead' (MX Used to read data from the BUS 400).

The DB table 485 may include a routing information table that registers a destination according to a source application ID and a branch condition and a class information table that registers class queue information.

The configuration file 490 represents a file in which configuration information necessary for the MX BUS 400 to operate is registered.

Hereinafter, the function and structure of the shared memory 425 capable of efficient control will be described with reference to FIG. 6.

The shared memory 425 is a means for storing data processed by application processes. The shared memory 425 is managed in units of pages of a constant size for efficient management of data. The MX BUS 400 creates a shared memory area for its own use at initial startup, and each application process delivers its capacity to the MX BUS 400 when it requests a session connection. The MX BUS 400 allocates capacity to each of the application processes using the DP Handler Class 420 within the available range at the request of the application processes.

Then, if any application process requests reading data, MX BUS 400 passes the location information in shared memory of the corresponding data to MX API 415. The MX API 415 transfers the location information to the DP Handler Class 420 to read the corresponding data from the shared memory, and delivers the read data to the corresponding application process.

On the contrary, when any application process requests to write data, the MX API 415 stores the data in the shared memory 425 using the DP Handler Class 420 and stores control information about the MX BUS 400. Write to

The data block in which data is stored in the shared memory 425 may be a data page header block (610a, 610b, 610n-hereinafter referred to as 'DPH') and a data page start block (depending on its role). Data Page Start Blocks 620a and 620b (hereinafter referred to as 'DPS') and Data Page Continuous Blocks (630a-referred to as 'DPC' below).

The DPHs 610a, 610b, and 610n are allocated to the first page of data blocks allocated to each application process, and management information is inserted rather than actual data. That is, the DPHs 610A, 610B, and 610N are headers indicating information on the shared memory area that can be used by each application process. The DPHs 610A, 610B, and 610N include an enable flag, a page count, and a connective DPH address (previous DPH address and next DPH address). The enable flag indicates whether the application process is using the entire area before the next DPH address. The connection is set to free so that other application processes can use this area. The page count represents the total number of pages available to the application process. The number of pages required between each application process may be different. For example, the Ga receiver 215 does not require a large number of page counts because it immediately processes the received data. On the other hand, the Aggregator 225 needs to store a large number of incomplete CDRs at the same time and therefore requires a large number of page counts. That is, it is dynamically allocated according to the operation characteristics of the corresponding application process. A linked DPH address is an address value that forms a bidirectional linked list structure with DPH used by other application processes. When the connection connection request is received, the DP Handler Class 420 sequentially searches for the next DPH address and allocates the next DPH address if the use flag of the corresponding address is set to free. In addition, when a connection release request is received, the DP Handler Class 420 sets the corresponding DPH to free and simultaneously searches for a connection DPH address and concatenates the corresponding area if the corresponding area is also free.

The DPSs 620a and 620b represent the first page of data that each application process will write to the shared memory 425, one for each data stored in the shared memory 425. The DPSs 620a and 620b include a availability flag, a page count, and a data length. The use flag indicates whether the page is currently in use. It is set to "used" at the time the data is written and set to free so that it can be reused when the application process that performs subsequent processing reads it in and finishes processing. The page count represents the number of counts of pages required for data storage. The page count is dynamically set according to the length of data to be stored. The data length represents the size in bytes of the actual data. The remainder of the DPS 620a, 620b is filled with actual data.

The DPC 630a is used to dynamically allocate the number of pages when the data length is larger than one page size to process variable length data. If the data length is smaller than the page size, it is not allocated.

The present invention can facilitate the allocation and / or release of the shared memory 425 area used by the corresponding application process at the start / end of each application process by structuring the shared memory required for data storage as described above. In addition, data processing of variable length can be facilitated.

7 is a data flow diagram illustrating a connection establishment process between application processes and MX BUS according to an embodiment of the present invention.

The application process must first establish a connection with the MX BUS 400 in order to transmit / receive control information with the MX BUS 400. 7 shows a process of establishing a connection between the application process and the MX BUS 400.

Referring to FIG. 7, in step 710, the MX API 415 transmits an Open Request to the MX BUS 400 through UDP by a request of an application process.

As described above, there is a Connection Mgr 455 in the MX BUS 400 that performs connection establishment and release. When the Open Mgr 455 receives an Open Request from the MX API 415, the Connection Mgr 455 generates an Audit class 475 for data recovery in step 715. The Connection Mgr 455 creates a Message Queue 435 used to send and receive control information (step 720) and allocates a shared memory 425 area for the session (step 725). Connection Mgr 455 also creates a Message I / O thread 440 for data routing (step 730). Thereafter, the Connection Mgr 455 transmits an Open Response including the address of the allocated shared memory 425 and the ID of the Message Queue 435 to the MX API 415. The transmitted Open Response is delivered to each application process through the MX API 415.

Hereinafter, a process in which each application process reads or writes data stored in the shared memory 425 using the MX BUS 400 while the connection is established between the application processes and the MX BUS 400 will be described.

First, a process in which an application process writes data to the shared memory 425 will be described.

Any application process writes data to the shared memory 425 using the MX API 415 and the DP Handler Class 420 and then queues a Write Request to the Message Queue 435. The Message I / O thread 440 reads a Write Request from the Message Queue 435 in a waiting state. The audit class 475 writes data to the audit file 480 for transaction guarantee, and the MID mgr 470 stores control information for transaction guarantee. In addition, the MID Location Manager 470 stores address information in a map so that an application process requiring further processing can find the corresponding data in the shared memory 425, and the Message router 450 sets a destination route. The control information is then inserted into the class queue 445 so that subsequent application processes can read the data. The Message I / O thread 440 then generates a Write Response and sends it to the corresponding application process.

Next, a process in which any application process reads data written in the shared memory 425 will be described.

If any application process queues a Read Request to the Message Queue 435 using the MX API 415, the Message I / O thread 440 reads it out of the waiting state. If control information corresponding to the class queue 445 of the session to be read exists, the MID mgr 470 stores the MID corresponding to the read data in a map and the Message I / O thread 440 Create response using control information. When the Message I / O thread 440 writes the generated response to the Message Queue 435, the MX API 415 reads data from the shared memory 425 in which the data exists using the control information. This is then passed on to the application process. However, if there is no information to read in the Class Queue 445, a response to the time-out is created after waiting for a certain time.

8 is a data flow diagram illustrating a connection release process between the application processes and the MX BUS according to an embodiment of the present invention.

Referring to FIG. 8, in step 810, the MX API 415 transmits a close request to the MX BUS 400 by a request of an application process.

When the MX BUS 400 receives a Close Request, the Connection Mgr thread 455 of the MX BUS 400 releases the shared memory 425 allocated to the session (815) and deletes the Message Queue 435. In step 820, the Message I / O thread 440 for data routing is terminated (step 825). In addition, the Connection Mgr thread 455 transmits a close response to the MX API 415 through UDP.

9 is a diagram illustrating a process of recovering an error generated in a data writing process according to an exemplary embodiment of the present invention.

If an application process (for example, the Ga receiver 215) that only writes data to the MX BUS 400 is restarted after termination, error recovery may be necessary. For example, if Ga (GPRS Tunneling Protocol Prime) is restarted after abnormal termination, the application process that writes data to MX BUS 400 lastly writes data to MX BUS 400 but fails to receive a response. In this regard, whether or not the MX BUS 400 has completed the corresponding data processing cannot be confirmed and there is a possibility of data duplication. A method for preventing this problem will be described with reference to FIG. 9.

Referring to FIG. 9. In the case of the Ga receiver 215, data is received from the GGSN or SGSN through the GPRS Tunneling Protocol Prime (Ga) interface and recorded in the MX BUS 400, and there is no read process from the MX BUS 400. . If the Ga receiver 215 records control information on the MX BUS 400 and terminates without receiving a response, it is necessary to check whether the MX BUS 400 processes the information that has already been transmitted upon restart. To this end, the Ga receiver 215 temporarily stores the last MID processed by each moment, and the MX BUS 400 also temporarily stores the MID that has been processed after receiving from the Ga receiver 215. When the Ga receiver 215 is restarted and requests a connection connection, the Ga receiver 215 attaches and transmits the last MID transmitted, and the MX BUS 400 compares it with the last MID that it processed. Discard prevents data duplication.

FIG. 10 is a diagram illustrating a process of recovering an error generated in a process of reading and writing data according to an exemplary embodiment of the present invention.

Error recovery may be required when an application process (for example, the adapter 220) that reads data from the MX BUS 400 and writes a processing result is restarted after termination. For example, if an abnormal termination occurs during a data processing process and restarted, processing of the corresponding data that was read in the last processing process but failed to complete the processing may be omitted. A method for preventing such a problem will be described with reference to FIG. 10.

Referring to FIG. 10, in the case of the adapter 220, after the Ga receiver 215 reads control information written to the MX BUS 400, the processing result is written to the MX BUS 400. )do. At this time, if the read data is not processed normally and restarted after being terminated, the MX BUS 400 must transmit the corresponding control information to the Class Queue 445 to be read by the Adapter 220 again. For this purpose, the MX BUS 400 temporarily stores the MID being processed by each application process in the MID Manager class 470 and deletes it when the processing is completed. When the application process is restarted after termination, control information about the MID existing in the MID Manager 470 is inserted into the Class Queue 445 to prevent omission.

11 is a diagram illustrating a process of recovering an error generated in a data reading process according to an exemplary embodiment of the present invention.

When the regulator 235 which reads data from the MX BUS 400 and delivers the processing result to the BS 145 is abnormally terminated, the MX BUS 400 normally processes the last data provided by the regulator 235. There is a possibility of duplication and / or omission of data as it cannot be verified. A method for preventing this problem will be described with reference to FIG.

Referring to FIG. 11, the regulator 235 transmits the processing result to the BS 145 without writing the processing result to the MX BUS 400. Therefore, when restarting after abnormal termination, the MX BUS 400 must retransmit if the last MID transmitted was not normally processed by the regulator 235. For this purpose, the regulator 235 temporarily stores the last MID processed by each moment and transmits it to the MX BUS 400 when a connection connection request is requested after restarting. The MX BUS 400 prevents data duplication by deleting a corresponding MID when it exists in the MID mgr 470 and inserts control information corresponding to the remaining MIDs into the Class Queue 445 to prevent data loss.

12 is a diagram illustrating an error recovery process when restarting after the termination of the MX BUS according to an embodiment of the present invention.

When the MX BUS 400 is restarted after termination, all data existing in the shared memory 425 are lost, and thus there is a possibility of data duplication. A method for preventing this problem will be described with reference to FIG. 12.

Referring to FIG. 12, since the control information in the MX BUS 400 and the data existing in the shared memory 425 are lost when restarted after the termination, the MX BUS 400 may perform a transaction in order to recover the problem. All data (ie, not completed) and control information thereof are stored in the audit file 480. That is, when the application process calls the write request, the control information and data thereof are stored in the audit file 480, and the processing is deleted when the application process is completed. When the MX BUS 400 is restarted after termination, the control information is read from the audit file 480 to determine the destination and inserted into the corresponding Class Queue 445. In this case, the storage location of the data is indicated by the audit file 480 so that the MX API 415 can read the actual data later.

Through the above-described methods, the present invention can prevent duplication and / or omission when each application process and / or MX BUS 250 is restarted after a normal or abnormal termination.

FIG. 13 is a diagram illustrating a load sharing process according to an exemplary embodiment of the present invention. FIG.

According to the present invention, when a bottleneck occurs in a specific step of a series of processes from the Ga receiver 215 to the regulator 235, load sharing may be started by additionally starting an application process that processes the process. can do. For example, if a sudden increase in the call volume and a large amount of data is received in the Ga receiver 215 for a unit time, the adapter 220 may be additionally activated for rapid processing. That is, the present invention can support a non-blocking mode during data transmission / reception in order to effectively perform the load distribution processing, and when multiple application processes having the same role access at the same time, separation for data processing to ensure isolation and continuity. The load balancing process of the present invention will be described with reference to FIG.

Referring to FIG. 13, in the MX BUS 400, a storage capable of queuing control information (that is, control information on generated and processed data) is provided for each input node on a routing path. There is a Class Queue 445. For example, the Ga receiver 215 stores the received data in the shared memory 425 and then records control information about the received data in the MX BUS 400. The MX BUS 400 reads it, determines the destination, and inserts it into the Class Queue 445 of the corresponding Adapter 220. When the control information is inserted into the Class Queue 445, the plurality of Ga receivers 215 can be inserted into the Class Queue 445 corresponding to the Adapter 220 at the same time, so separation of data processing can be eliminated. To ensure that a locking method is applied. In addition, in order to support the non-blocking mode (non-blocking mode) by using a broadcasting method (broadcasting method) to notify a plurality of adapters 220 that the control information has been inserted. Among the adapters 220 that are waiting in the non-blocking mode, the adapter 220 that receives the notification reads the control information from the class queue 445. However, at this time, since several adapters 220 can read control information from the class queue 445 at the same time, a locking method is applied. The read control information is transmitted to the corresponding application process through the MX API 415. The MX API 415 reads the actual data from the shared memory 425 using address information in the control information so that the corresponding application process can process it.

As described above, the present invention improves processing efficiency in a distributed processing environment by using a function of allocating class 445 resource and waiting in broadcasting and non-blocking state. Ensure consistency of data processing.

As described above, the WCDMA packet charging data processing method and system according to the present invention is a type and characteristic of each CDR in a multi-process environment for processing charging information generated in a universal mobile telecommunication system (UMTS) packet switched core network (PS-CN). Provides a universal function for routing data to the appropriate process.

In addition, the present invention facilitates system development by the components included in the charging gateway adopt the same data routing scheme.

In addition, the present invention can easily change the routing path of the charging information only by updating the control information in the case of adding the charging CDR.

In addition, the present invention can route only the control information when charging data brokering or integration, and the actual charging data is stored in the shared memory to maintain improved performance even when processing a large amount of data.

In addition, the present invention adopts a shared memory structure suitable for CDR processing to enable data processing of variable length, and facilitate the allocation and release of shared memory resources.

In addition, the present invention can maintain continuity with respect to data processing upon restarting after termination (normal termination or abnormal termination) of each component of the charging gateway, thereby preventing duplication or loss of charging information.

In addition, the present invention supports a non-blocking mode to enable load sharing and distributed processing, thereby preventing bottlenecks during load concentration.

Although the above has been described with reference to a preferred embodiment of the present invention, those skilled in the art to which the present invention pertains without departing from the spirit and scope of the present invention as set forth in the claims below It will be appreciated that modifications and variations can be made.

Claims (20)

An apparatus for processing packet charging data, Shared memory for storing charging data, wherein the charging data includes raw charging data, partial charging data and complete charging data; Receive raw billing data from at least one billing data generating device and store it in the shared memory, generate the full billing data using the raw billing data, store the full billing data in the shared memory, the shared memory An application layer for generating control information corresponding to the charging data stored in the mobile terminal, and transferring the complete charging data to a billing system, wherein the control information includes a MID for verifying the control information; Storage location information, including routing destination information; And Receiving and temporarily storing the control information, including the Mx bus (MX BUS) for transmitting the received control information to any application process included in the application layer, The region in which the charging data is stored in the shared memory is designated at the time of startup of the MX bus, and the designated shared memory region is individually allocated to a plurality of application processes included in the application layer. Billing data processing unit. The method of claim 1, The application layer, A plurality of application processes; MX Application Process Interface (MX API), which provides a method for the application process to interact with the MX bus, wherein the method is Open () for connection connection between the application layer and the MX bus. , At least one of Close () for disconnection, Read () for reading data, and Write () for writing data; A memory manager (DP Handler Class) for managing an individual shared memory area allocated corresponding to each of the application processes, and storing the charging data by an arbitrary application process in the individual shared memory area; And Transferring the control information generated by any application process storing the charging data in the respective shared memory area to the MX bus, receiving the control information from the MX bus, and transferring the control information to a corresponding application process. Include a Message Queue Class, The plurality of application processes, A billing data receiver configured to receive the raw billing data from the billing data generator and store it in the shared memory; A decoder for decoding the raw billing data and storing it in the shared memory; An aggregator for integrating incomplete charging data into one full charging data when incomplete charging data is present among the decoded raw charging data, and storing the integrated complete charging data in the shared memory; A collector for converting the complete billing data into a predetermined form for processing in the billing system; And Packet charging data processing device, characterized in that each corresponding to any one of the regulator (regulator) for transferring the charging data converted by the collecting unit to the charging system. The method of claim 2, The MX bus transmits a subsequent processing request to the integration unit or the collection unit by using routing destination information included in the control information received from the decoding unit, Each application process performs a predetermined data processing using the charging data stored in the shared memory corresponding to the control information received from the MX bus. The method of claim 2, When a connection connection request is received from the MX application process interface, the MX bus temporarily stores charging data being processed by the plurality of application processes and control information corresponding to the charging data, and the application processes After generating a message queue for transmitting and receiving control information, and designating the shared memory area, and generating a message I / O for routing any control information, the M-X application The connection is made by sending a connection connection response to each application process through the process interface. And the connection connection response includes an individual shared memory area address and a message queue ID assigned to the application process. The method of claim 1, The shared memory is allocated in units of pages of a predetermined size, at least one data page header block, at least one data page start block dependent on one data page header block. And one or more Data Page Continuous Blocks dependent on one Data Page Start Block, The data page header block is allocated one for each application process, and includes information on whether to use a storage area corresponding to the data page header block. The data page start block indicates the first page where each application process can write charging data, And the data page contiguous block is dynamically allocated to process charging data of variable length when the length of the charging data is greater than one page size. The method of claim 5, And when information on whether the data page header block is used indicates unused information, a storage area corresponding to the data page header block is dynamically allocated to another application process. The method of claim 5, The charging data stored in the data page start block and the data page consecutive block is deleted when a corresponding subsequent application process reads and processes the charging data, and the usage information is set to not used. Device. The method of claim 1, And the MID includes packet charging data processing device identification information, application process identification information, and sequence information corresponding to a processing order of an application process corresponding to the application process identification information. The method of claim 2, The billing data receiver temporarily stores the MID of the finally processed control information, and if the billing data receiver is restarted after abnormal termination, the billing data receiver sends the MID to the MX bus, The MX bus transmits a request for processing the billing data corresponding to the MID to the billing data receiver when the MID received from the billing data receiver is inconsistent with a temporarily stored process completed MID. Device. The method of claim 2, When the MX bus receives a read request for any raw billing data from the decoding unit, the MX bus transmits control information on the raw billing data to the decoding unit, and transmits a MID corresponding to the transmitted control information. Temporary storage, And if the decoding unit is restarted after abnormal termination, retransmitting control information corresponding to the stored MID to the decoding unit. The method of claim 2, When the transfer unit is restarted after abnormal termination, the transfer unit transmits the MID of control information corresponding to the complete charging data finally transmitted to the charging system to the MX bus. The M-X bus deletes the MID matching the received MID from one or more temporarily stored MID, and transmits the control information corresponding to the remaining MID to the transfer unit. A method for processing packet charging data in a packet charging processing apparatus including an application layer, an MX bus, and a shared memory, wherein the application layer includes a billing data receiver, an decoder, an integrated device. Includes a plurality of application processes corresponding to an aggregator, a collector, and a regulator; Receiving, by the charging data receiving unit, the raw charging data from the charging data generating device and storing the raw charging data in the shared memory, and generating first control information corresponding to the stored raw charging data and transferring the generated charging data to the M-bus; Wherein the control information includes a MID for verifying the control information, storage location information of the charging data, and routing destination information; The MX bus transferring the first control information to the decoding unit for subsequent processing of the raw charging data; The decoding unit reads, decodes and stores the raw charging data corresponding to the first control information in the shared memory, and then generates and transmits the second control information corresponding to the stored decoded raw charging data to the MX bus. Doing; Transmitting, by the MX bus, the second control information to the collection unit when the decoded raw charging data is full charging data; The collection unit reads the complete billing data corresponding to the second control information, converts it into a form that can be processed by a billing system, stores it in the shared memory, and generates corresponding third control information. Transferring to the MX bus; Transmitting, by the MX bus, the third control information to the transfer unit; And Wherein the transfer unit comprises the step of reading the converted charging data corresponding to the third control information from the shared memory to the charging system, The region in which the charging data is stored in the shared memory is designated at the time of startup of the MX bus, and the designated shared memory region is individually allocated to a plurality of application processes included in the application layer. How billing data is processed. The method of claim 12, Transmitting, by the MX bus, the fourth control information to the integration unit when partial charging data exists among the decoded raw charging data; And The integrating unit may further include: integrating a plurality of incomplete charging data, storing integrated complete charging data in the shared memory, and generating fourth control information corresponding to the complete charging data, and transmitting the fourth control information to the MX bus. Packet charging data processing method characterized in that. The method of claim 12, The MX bus receiving a connection connection request from the application layer; The MX bus performing a connection connection; And And sending a connection connection response to the application layer. The MX bus temporarily stores charging data being processed by the plurality of application processes and control information corresponding to the charging data, and generates a message queue for transmitting and receiving control information with the application processes. Specify a shared memory area, generate a message input / output unit (Message I / O) for routing arbitrary control information, and perform a connection connection; And the connection connection response includes an individual shared memory area address and a message queue ID assigned to the application process. The method of claim 12, The shared memory is allocated in units of pages of a predetermined size, at least one data page header block, at least one data page start block dependent on one data page header block. And one or more Data Page Continuous Blocks dependent on one Data Page Start Block, The data page header block is allocated one for each application process, and includes information on whether to use a storage area corresponding to the data page header block. The data page start block indicates the first page where each application process can write charging data, And the data page contiguous block is dynamically allocated to process variable length billing data when the length of the billing data is greater than one page size. The method of claim 15, And when information on whether the data page header block is used indicates unused information, a storage area corresponding to the data page header block is dynamically allocated to another application process. The method of claim 12, And the MID includes packet charging data processing device identification information, application process identification information, and sequence information corresponding to a processing order of an application process corresponding to the application process identification information. The method of claim 12, Temporarily storing the MID of the control information finally processed by the charging data receiver; Transmitting, by the charging data receiver, the MID to the MBUS when the charging data receiver is restarted after abnormally terminating; Determining, by the MX bus, whether the MID received from the charging data receiver matches the processed MID temporarily stored in the MX bus; And And in case of inconsistency, transmitting the request for processing the billing data corresponding to the MID to the billing data receiver. The method of claim 12, Transmitting, by the MX bus, the first control information to the decoding unit when a read request for any raw charging data is received from the decoding unit; The MX bus temporarily storing a MID corresponding to the transmitted control information; Determining, by the MX bus, whether the decoding unit has been restarted after abnormal termination; And Re-starting after abnormal termination, the MX bus further comprises the step of retransmitting control information corresponding to the stored MID to the decoding unit. The method of claim 12, When the transmission unit is restarted after abnormal termination, transmitting the MID of control information corresponding to the complete charging data finally transmitted to the charging system to the MX bus; Detecting an MID that matches the received MID from one or more MIDs temporarily stored in the MX bus; And If there is a matching MID, transmitting the control information corresponding to the remaining mismatched MID to the delivery unit.

Images