WO2009038384A1

WO2009038384A1 - Query processing system and methods for a database with packet information by dividing a table and query

Info

Publication number: WO2009038384A1
Application number: PCT/KR2008/005554
Authority: WO
Inventors: Kyung-Woo Nam
Original assignee: Haechang Systems Co., Ltd.
Priority date: 2007-09-20
Filing date: 2008-09-19
Publication date: 2009-03-26
Also published as: KR100835654B1

Abstract

Disclosed are a system and method for searching the information about call- flows in real-time over a Voice over Internet Protocol (VoIP) network by capturing all the packets, storing packet flow data extracted from the captured packets in the packet information DB, and sending a searching request to the packet information DB. The system includes a packet information DB configured with a plurality of packet information tables having the same structure; a packet capturing device that captures all packets over the VoIP network, extracts packet flow information from the captured packets, and stores the packet flow information with a capturing time as a generation time (GT) in one of packet information tables in sequence of GTs; and a search query processor that receives a primitive search query for a packet flow information, makes each table-specific query from the primitive search query for each of the packet information tables, sends a request for the table-specific queries to the packet information DB, and returns them. The system and method can improve a search rate for a real-time call-flow search by capturing packets in real time even when the number of packets transmitted from the VoIP network is large.

Description

[DESCRIPTION]

[Invention Title] QUERY PROCESSING SYSTEM AND METHODS FOR A DATABASE WITH

PACKET INFORMATION BY DIVIDING A TABLE AND QUERY [Technical Field]

The present invention relates to a system and method for capturing all the packets transmitted over a Voice over Internet Protocol (VoIP), extracting packet flow data from the captured packets, storing them in the packet information table divided into a plurality of tables with the same structure, and searching for a call-flow request by dividing a request query into executable queries corresponding to each of the divided tables.

[Background Art]

VoIP service is a communication service technology for converting voice data into IP data packets and transmitting the IP data packets over a data communication packet network (for example, the Internet). A user may receive a service using a terminal device at an end of the VoIP network, like an analog telephone.

A configuration of the VoIP network will be described in detail with reference to FIG. 1. In general, an IP Private Branch Exchange (PBX) 110 is needed to provide a communication service like an analog telephone service over the VoIP network. The IP PBX 110 is a device for connecting a call requested from an Internet telephone terminal 135 to a destination telephone terminal 135 by finding the destination telephone terminal 135. The IP PBX 110 functions like a Public Switched Telephone Network (PSTN) PBX. To commercially provide a special service, a provider includes a large-capacity IP PBX 110 and connects the IP PBX 110 to a VoIP network 130 through a backbone switch 132. When the IP PBX 110 receives voice packets of the telephone terminal 135 over the VoIP network 130, it finds the telephone terminal 135 and transmits them to it. Also, in the case of an analog telephone terminal 125, not an Internet telephone terminal 135, the PBX 110 establishes a connection through a trunk gateway 122. The PBX 110 receives a call from the analog telephone terminal over a PSTN 120 and connects the call to the Internet telephone terminal 135.

The VoIP service converts voice data into packets and transmits them over a data communication packet network. As shown in FIG. 2, the VoIP devices 150 relay the packets. Conventionally, the VoIP devices 150 are a proxy server 115, the IP PBX 110, the trunk gateway 122, etc. As a data communication protocol for VoIP, an H.323 standard has been usually used from the past, but now Session Initiation Protocol (SIP) which has a simple structure gets widely used.

FIG. 3 shows a protocol stack of a VoIP system using SIP. The VoIP protocol used in a SIP server is mainly used for call setup and implemented at a higher level than User Datagram Protocol (UDP). To actually transmit voice data, the VoIP protocol is implemented at a higher level than Real-time Transport Protocol/Real-time Transport Control Protocol (RTP/RTCP). That is, a packet of the former is configured with <IP Header + UDP Header + SIP Protocol> and a packet of the latter is configured with <IP Header + RTP/RTCP Header + Voice Data to be transmitted>. When a packet is captured and analyzed, <Call ID>, <Method>, ^Transmission Time>, <Telephone Terminal Information^ <Source Telephone Number>, <Destination Telephone Number>, etc. may be extracted as call-related information, and <Source IP/Port> and <Destination IP/Port> in the flow between the devices may be extracted. Here, the source IP/Port and destination IP/Port indicate port numbers in which the session with IP of devices is established and may be changed whenever a relay operation is performed through the VoIP devices 150. The source/destination telephone number is a telephone number of a corresponding telephone terminal 135. In general, an Internet telephone number is expressed as <Telephone Number>@<Domain>. Telephone terminal information includes information of a product name of a telephone terminal, etc. Method indicates types of call setup messages based on the SIP protocol. Referring to a method-specific packet flow, a call-setup progress state may be detected.

To observe whether packets are normally transmitted and received or whether a call flow is normally connected from a telephone terminal to an end, a packet analyzer 100 or a packet probe is used in the VoIP network. To temporarily observe the performance or flow of the VoIP network, packet flow information is gathered by connecting the packet analyzer 100 to the backbone switch 132 as shown in FIG. 1. The packet analyzer 100 captures and analyzes all packets passing through the connected backbone switch. Since the number of packets to be processed is very large, the packet analyzer 100 is only used once to detect the status of the VoIP network, but does not perform a real-time monitoring function.

In an example of the VoIP network of one provider at present, the number of packet flow information elements to be captured and analyzed in the backbone switch is about 150,000,000 per day. When the Internet telephone service is generalized, even more packet flow information should be processed. To address this problem, multiple packet probes 105 are installed to reduce the number of packets to be probed by one packet probe 105, as shown in FIG. 4, thereby attempting to probe all packets in real time. In general, the packet probe 105 is installed according to a unit network connected to the backbone switch. Accordingly, a corresponding packet probe captures and analyzes only packets transmitted from a unit network.

However, this method has a problem in that a delay time may occur in detecting a packet transmission state of the entire VoIP network since a bottleneck phenomenon occurs in the packet probe 105 installed in a unit network when the number of packets to be transmitted from the unit network is large. Since the multiple packet probes 105 are installed in the above-described method, installation and management costs significantly increase. The most important point is that it is difficult to detect the status of the entire VoIP network by merging data probed by the packet probes 105. [Disclosure] [Technical Problem]

The present invention has been made to address the above problems and provides a system and method for capturing all the packets transmitted over a Voice over Internet Protocol (VoIP), extracting packet flow data from the captured packets, storing them in the packet information table divided into a plurality of tables with the same structure, and searching for a call-flow request by dividing a request query into executable queries corresponding to each of the divided tables.

The present invention also provides a system and method for capturing all packets through a packet capturing device installed in a backbone switch of a VoIP network, storing packet flow data extracted from them by dividing data with reference to their capturing time, and searching for a call-flow request by dividing a request query into executable queries, which makes it possible to monitor the network in real-time for all days.

The present invention also provides a system and method that can allow a VoIP network manager to search for all types of desired requests about packet flow information by storing all the packet flow data for all the packets over a VoIP network.

The present invention also provides a system and method that can generate a packet information DB by extracting only required and basic data to reduce an amount of data to be stored while capturing a large number of packets in a plurality of packet capturing devices.

[Technical Solution]

According to the present invention, a method for searching packet flow information in real time by capturing all the packets transmitted over a Voice over Internet Protocol (VoIP), includes: (a) configuring a packet information DB with a plurality of packet information tables having the same structure; (b) capturing and temporarily storing packets transmitted over the VoIP network; (c) periodically extracting packet flow information from the captured packets, and storing the packet flow information with a capturing time as a generation time (GT) in one of packet information tables in sequence of GTs; (d) making a primitive search query for packet flow information, the primitive search query regarding the plurality of packet information tables as one table; (e) making table-specific queries from the primitive search query, each table-specific query corresponding to each of the packet information tables; and (f) sending a request for the table-specific queries to the packet information DB and acquiring the result of the request. In step (a), the packet information tables may have the same size, and the number of tables and the table size may be determined by the number of packets to be captured, a query processing ability of the DB, and a storing period.

The packet flow information may include <Call ID>, <Source Telephone Number>, <Destination Telephone Number>, <Method>, <Telephone Terminal

Information^ <Source IP/Port>, and <Destination IP/Port> as the packet flow data extracted from the packets, and further comprises <Generation Time (GT)> as the packet capturing time.

In step (b), a life-time of packets which are temporarily stored is set to be longer than a period of step (c).

In step (c), the packet flow information may be sequentially stored in the plurality of packet information tables with reference to the generation time, and may be cyclically stored from a first table when a last table is full with the current packet flow information. In step (e), the table- specific queries may be combined by a UNION command.

In step (e), the table-specific query may be created for only packet information table in which some parts of generation time ranges (GTRs) are included in a generation time range (GTR) condition of the primitive search query In step (e), a GTR condition in a condition statement of the table-specific query may be defined in a range satisfying both the GTR condition within the primitive search query and a GTR of a packet information table to be referred to, and the GTR condition may be placed in a head of the condition statement of the table-specific query.

According to the present invention, a system for searching packet flow information in real time by capturing all the packets transmitted over a Voice over

Internet Protocol (VoIP) includes: a packet information DB configured with a plurality of packet information tables having the same structure; a plurality of packet capturing devices that capture packets transmitted over the VoIP network, and periodically, extract packet flow information from the captured packets, and store the packet flow information with a capturing time as a generation time (GT) in one of packet information tables in sequence of GTs; and a plurality of call-flow search terminals that make a primitive search query for packet flow information, the primitive search query regarding the plurality of packet information tables as one table, and acquire the request for the table-specific queries by sending the request to the packet information DB. Each of .the plurality of packet capturing devices may include: a packet capture unit that captures and temporarily stores packets transmitted over the VoIP network; and a packet information generator that periodically generates packet flow information extracted from the captured packets, inserts a packet capturing time as a generation time (GT) into the packet information, and stores the packet flow information in the packet information tables.

The packet flow information may include <Call ID>, <Source Telephone Number>, <Destination Telephone Number>, <Method>, <Telephone Terminal Information^ <Source IP/Port>, and <Destination IP/Port> as the packet flow data extracted from the packets, and may further include <Generation Time> as the packet capturing time.

The packet information generator may sequentially store the packet flow information in the packet information tables with reference to the generation time, and cyclically store the packet flow information from a first table when a last table is full with the current packet flow information. The table-specific queries may be combined by a UNION command.

According to the present invention, a system for searching packet flow information in real time by capturing all the packets transmitted over a Voice over Internet Protocol (VoIP), includes: a packet information DB configured with a plurality of packet information tables having the same structure; a plurality of packet capturing devices that capture packets transmitted over the VoIP network, and periodically, extract packet flow information from the captured packets, store the packet flow information with a capturing time as a generation time (GT) in one of packet information tables in sequence of GTs; and a search query processor that receives a request for a primitive search query for a packet flow information, makes table-specific queries from the primitive search query, each table-specific query corresponding to each of the packet information tables, sends a request for the table-specific queries to the packet information DB, and returns the result of the request received from the packet information DB.

Each of the plurality of packet capturing devices may include: a packet capture unit that captures and temporarily stores packets transmitted over the VoIP network; and a packet information generator that periodically generates packet flow information extracted from the captured packets, inserts a packet capturing time as a generation time (GT) into the packet information, and stores the packet flow information in the packet information tables. The packet flow information may include <Call ID>, <Source Telephone

Number>, <Destination Telephone Number>, <Method>, <Telephone Terminal Information^ <Source IP/Port>, and <Destination IP/Port> as the packet flow data extracted from the packets, and further include <Generation Time> as a packet capturing time. The packet information generator may sequentially store the packet information in the plurality of packet information tables with reference to a generation time, and cyclically store the packet information from a first table when the packet information is stored in a last table.

After creating table-specific queries for referring to packet information tables from the primitive search query, the search query processor may create a divided search query by combining the table-specific queries in response to a UNION command. [Description of Drawings]

FIG. 1 is a diagram showing a configuration of a conventional VoIP network. FIG. 2 shows a packet flow in the conventional VoIP network. FIG. 3 shows a stack structure of a VoIP protocol.

FIG. 4 is a diagram showing a configuration of a conventional device for measuring the performance of a VoIP network through packet analysis.

FIG. 5 is a diagram showing a configuration of a packet information search system (PISS) according to an exemplary embodiment of the present invention. FIG. 6A is a diagram showing a structure of a packet information DB according to an exemplary embodiment of the present invention.

FIG. 6B shows a structure of a packet information table according to an exemplary embodiment of the present invention. FIG. 7 shows an example of optimizing an operation for dividing and optimizing a query requested by a user in a call-flow search terminal according to an exemplary embodiment of the present invention.

FIG. 8 is a flowchart showing a method for dividing a DB and a query for packet information according to an exemplary embodiment of the present invention. FIG. 9 is a diagram showing a configuration of a packet information search system according to another exemplary embodiment of the present invention.

FIG. 10 shows an example of a screen displayed by re-configuring a call flow through found packet information according to the present invention.

[Modes of the Invention] Hereinafter, a system and method for searching a call flow by dividing a DB and a query for packet flow information will be described in detail with reference to the accompanying drawings.

FIG. 5 is a diagram showing a configuration of a packet information search system (PISS) according to an exemplary embodiment of the present invention. As shown in FIG. 5, a PISS 200 includes a packet information DB 220, a plurality of packet capturing devices 201 each configured with a packet capture unit 210 and a packet information generator 230, and a plurality of call-flow search terminals 250.

The packet capturing device 201 captures packets in connection with a backbone switch 132 of a VoIP network 130 and periodically extracts packet flow information to store the extracted packet flow information in the packet information DB 220. The plurality of packet capturing devices 201 can be connected to the backbone switch 132.

That is, the packet capturing devices 201 can be installed to capture all packets at positions where the packets can be captured, to extract only required packet flow data from captured packets, and to store them in the packet information DB 220. The packet capture unit 210 connected to the backbone switch 132 of the VoIP network 130 captures all packets transmitted from the backbone switch 132. Unit VoIP networks connected to the backbone switch 132 are usually switched. The backbone switch 132 can be connected to another backbone switch 132. Preferably, one packet capture unit 210 connected to the backbone switch 132 may capture packets. The packet capture unit 210 captures all packets and stores the captured packets in a temporary file along with a packet capturing time. The packet capturing time becomes a packet information generation time (GT). The packet information GT is used for a packet information search. The packets are stored for a relatively short time, but the packet storage time is longer than a period of extracting packet flow information and generating a DB therefor. This is because of the unavailability of an infinitely large temporary storage space to capture and store continuously transmitted packets.

The packet information DB 220 is configured with a plurality of packet information tables having the same structure as tables capable of storing packet flow information.

A structure of the packet information DB 220 will be described in detail with reference to FIG. 6. FIG. 6 A shows a preferred exemplary embodiment of the structure of the packet information DB and FIG. 6B shows a preferred exemplary embodiment of a structure of a packet information table. As shown in FIG. 6, the packet information DB 220 is configured with M packet information tables 221. All the packet information tables 221 have the same structure. That is, the tables have the same field names and field sizes. Preferably, the tables may have the same table size with R records. The number of packet information tables 221 and the table size (or the number of records per table) are determined by the number of packets to be captured, a query processing ability of the DB, and a period of storing packet flow information.

An example of capturing 150,000,000 packets per day will be described. When the number of records of a table increases, a query processing rate for the table decreases. The number of records is determined by a time of processing a requested query. In the above-described example, the number of records of the packet information table 221 is about 1,000,000. When a policy of storing data for 30 days is established, the number of packet information tables 221 is set to about 5,500 (= 30*150,000,000/1,000,000).

As shown in FIG. 6B, the structure of the packet information table 221 includes <Call ID>, <Source Telephone Number>, <Destination Telephone Number>, <Source IP/Port>, and <Destination IP/Port>, <Method>, <Generation Time>, and <Telephone Terminal Information>. <Call ID>, <Method>, <Telephone Terminal Information>, <Source Telephone Number>, and <Destination Telephone Number> are call-related information related to the VoIP protocol. <Source IP/Port> and <Destination IP/Port> are device information upon transmission between devices. <Generation Time> is a packet capturing time.

A generation time range(GTR) of each packet information table 221 is defined with reference to a GT, and a sequence of the packet information tables 221 is defined by their GTRs. For example, assuming that a first packet capturing time(or the starting GT) is 12:00 and the length of GTR of the packet information table 221 is set to a unit of 10 minutes, a first packet information table 221 stores only packet flow information about packets captured from 12:00 to 12:10 and the GTR of the table is from 12:00 to 12:10. A second packet information table 221 stores only packet flow information about packets captured from 12:11 to 12:20 and the GTR of the table is from 12:11 to 12:20. This means that GTs of packet flow information in the table should be included in the GTR of the table. The GTRs could be calculated when the length of GTRs is constant and the starting time is set. The GTR length of each table may be arbitrarily adjusted by the number of captured packets. It is in the case that when a table is filled out with the packet flow information, the next table gets to store the packet. The GTR length of the table depends on the range of GTs of packets whose packet flow information is stored in the table. That is, the more is the number of packets per a unit time, the shorter the GTR length of the table.

The packet information generator 230 converts the packet flow information from packets captured by the packet capture unit 210 and its GT suitably for the structure of the packet information table 221, and stores the converted information and time in the table. A sequence of tables, from the first to M^th packet information tables 221, is defined by their GTRs. The GTR is defined in each packet information table 221. As described above, when the packet information tables 221 are divided in units of 10 minutes, packet flow information is stored in the first table for 10 minutes the first time and in the second table for the next 10 minutes. In another embodiment, the first packet flow information is stored in the first packet information table 221. When the first packet information table 221 is full, packet flow information is stored in the next table, that is, the second packet information table 221. The former method has a disadvantage in that tables may not be filled out, but has an advantage in that a generation time range (GTR) of each table may be simply calculated. On the other hand, the latter method has an advantage and disadvantage opposite to the former method.

When the M^th packet information table 221 is finished to be stored, packet flow information is stored again from the first packet information table 221. In this case, previously stored packet flow information is lost. That is, the packet flow information is only stored for a given time. In the packet information generator 230, a process for storing captured packets is periodically repeated at a given time interval. When the packet capture unit 210 captures packets during a given time and stores the captured packets in a temporary file, the packet information generator 230 periodically extracts packet flow information from the packets and stores the extracted packet flow information in the packet information tables 221.

The call-flow search terminals 250 serve as clients related to a server with respect to the packet information DB 220. When the call-flow search terminal 250 as the client sends a search query for some packet flow information to the packet information DB 220, the packet information DB 220 processes the query. Accordingly, the call-flow search terminal 250 acquires information about packet flows. A call is determined by <Source Telephone Number> and <Destination Telephone Number> of the packet flow information and VoIP devices 150, through which each call passes, are determined by <Source IP/Port> and <Destination IP/Port>. VoIP devices used in a call flow can be detected by finding all packet flow information with the same <Source IP/Port> and <Destination IP/Port>.

The search queries from the call-flow search terminals 250 to the packet information DB 220 will be described in detail with reference to FIG. 7. FIG. 7 shows an example of optimizing an operation for dividing and optimizing a search query by a user in a call-flow search terminal according to an exemplary embodiment of the present invention. FIG. 7A shows a primitive search query and FIG. 7B shows table- specific queries into which the primitive search query of FIG. 7A is divided.

Queries are classified into a primitive search query 310 and search queries 320 into which the primitive search query 310 is divided.

As shown in FIG. 7A, the primitive search query 310 is created by regarding the plurality of packet information tables 221 as one table. In the statement of the primitive search query 310, <Table Name> in "FROM <Table Name>" is written as the entire table name of <DayRegi>. As shown in FIG. 7B, the table-specific queries 320 are created by dividing the primitive search query 310 suitably for the plurality of packet information tables 221. Which packet information table 221 is to be referred to by a primitive search query is determined by analyzing the search query 310. Each table-specific query is created according to each of tables to be referred to. Which packet information table 221 is to be referred to by the primitive search query 310, is determined by a <Generation Time(GT)> condition of a WHERE clause as a condition statement of the query. That is, since the packet information tables 221 are divided by the GTRs, it is the referred tables which stores packet flow information satisfying the GT condition of the primitive search query 310. That is, the table-specific query is created for only packet information table in which some parts of generation time ranges (GTRs) are included in a generation time range (GTR) condition of the primitive search query.

For example, since the condition of <Generation Time> in the primitive search query of FIG. 7A is between 3:10 and 4:25, all packet information tables 221 of which the GTR is related with the range of the condition are effective. That is, a <DayRegi- Kl> table between 3:10 and 3:20, a <DayRegi-K2> table between 3:20 and 3:30, — , a <DayRegi-K8> table between 4:20 and 4:25 are effective.

The table-specific queries for packet information tables 221 are created as follows. The table-specific queries are the same as the search query, except for <Table Name> and <Geheration Time(GT)> items. <Table Name> is replaced with names of the packet information tables 221 to be referred to. The <Generation Time> condition is narrowed to within the GTR of the packet information tables 221 to be referred to, since each table stores only packet flow information whose GT is included in the GT.

As shown in FIG. 7B, the FROM statement in the last table-specific query is conditioned by the corresponding table name <DayRegi-K8>. While the GTR of a table <DayRegi-K8> is from 4:20 to 4:30 as shown in FIG. 7B, the GT condition of a table- specific query is narrowly defined by <Between 4:20 and 4:25>.

A query is optimized by first writing a GT in a condition statement of a table- specific query 321. This is because a faster search can be performed in the DB when a GT item is used as an index.

When table-specific queries 321 for tables are created as described above, all results are combined using a UNION command for combining the queries.

When a search query is divided and combined by using the UNION command as described above, the processing rate of the combined query significantly increases. As the size of a table, that is, the number of records in the table, increases, the query processing rate decreases. Specifically, when the size increases to a certain extent, the query processing rate may rapidly decrease, which is caused by internal problems of the computer, such as a process processing method and a memory management method.

As the number of records increases, a process context switch and memory swap exceeds the processing capacity of the conventional CPU and the processing rate rapidly decreases. When processing is sequentially performed by limiting the table size to a given size, the rapid degradation of the processing rate can be prevented.

When the search queries are generated, the call-flow search terminal 250 sends a request for the search queries to the packet information DB, receives a search result, and re-configures call flow information. Since the packet information DB stores substantially all packet flow information until a given time, desired information can be extracted and viewed in any form. Since the query processing rate is high, time- consuming queries can also be processed in a match search of part of a data word, etc. Specifically, processing can be performed such that a user does not feel the degradation of the processing rate. That is, queries may be configured and processed in a form desired by a manager. The call-flow search terminal 250 mainly searches for packet flow information for the purpose of analyzing and monitoring a call flow.

FIG. 8 is a flowchart showing a method for dividing a DB and a query for packet flow information according to an exemplary embodiment of the present invention. As shown in FIG. 8 A, the method for dividing the DB and the query for packet flow information includes: (a) packet information DB dividing step S410, (b) real-time packet capturing step S420, (c) packet information storage step S430, (d) primitive search query generation step S440, (e) divided search query generation step S450, and (f) query request and result generation step S460. In step (a), a packet information DB is configured with a plurality of packet information tables having the same structure (S410). Specifically, in step (a), the tables have the same size, and the number of tables and the table size are determined by the number of packets to be captured, a query processing ability of the DB, and a packet information storing period. The structure of the packet information table includes <Call ID>, <Source Telephone Number>, <Destination Telephone Number>, <Source IP/Port>, and <Destination IP/Port>, <Method>, <Generation Time>, and <Telephone Terminal Information^

In step (b), all packets transmitted over the backbone switch 132 are captured in connection with the backbone switch of the VoIP network, and the captured packets are stored in a temporary file along with a packet capturing time (S420). Specifically, in step (b), a life-time of packets which are temporarily stored is set to be longer than a period of step (c).

In step (c), packet flow information is periodically generated by extracting packet flow information from the captured packets , a packet capturing time as a GT is inserted into the packet flow information, and the packet flow information is divided and stored in the plurality of packet information tables (S430). Specifically, in step (c), the packet flow information is sequentially stored in the plurality of packet information tables in sequence of GTs, and is cyclically stored from a first table when the packet flow information is stored in a last table. In step (d), a primitive search query is created by regarding the plurality of packet information tables as one table (S440). The plurality of packet information tables are configured, but their structures are the same. The packet information tables may be conceptually regarded as one table. Specifically, from the viewpoint of a client, a search query may be conceptually created without knowing the internal structure of the packet information DB. That is, <Table Name> of "FROM <Table

Name>" in a statement of the primitive search query is written as the entire table name.

In step (e), table-specific queries into which the primitive search query is divided according to the plurality of packet information tables are created (S450).

Specifically, in step (e), the table-specific queries are combined by a UNION command. Preferably, in step (e), table-specific queries are created for only packet information tables in which some parts of GTRs are included in a GTR condition of the primitive search query. More preferably, in step (e), a GT condition in a condition statement of the table- specific query is defined in a range satisfying both the GTR condition within the primitive search query and a GTR of a packet information table to be referred to, and the GT condition is placed in a head of the condition statement of the table-specific query.

More specifically, as shown in FIG. 8B, step (e) includes the steps of (el) acquiring information about time-based storage ranges for the tables of the packet information DB (S451), (e2) determining packet information tables whose time-based storage ranges are included in a GT condition of the primitive search query (S452), (e3) creating table-specific queries for only the determined tables to be referred to (S453), (e4) adjusting a GT condition in a condition statement of each table-specific query to be included in a time-based storage range of a table (S454), (e5) writing the GT condition in the condition statement of each table-specific query before conditions within the query (S455), and (e6) generating a combined search query by combining all the table- specific queries using a UNION command (S456).

Since the packet flow information is sequentially stored in the packet information tables according to a GT, GT information is essential to divide and optimize the query. This is because tables to be referred to for the primitive search query can be found when only tables corresponding to a GT condition can be detected. Since the packet information tables are sequentially stored according to a GT, a series of tables are referred to for the primitive search query. Queries for the tables have the same information as the primitive search query, but have reference table names that are different from the entire table name. A <Generation Time> condition in each table- specific query is re-set for query optimization. That is, since a packet GT within each table is included in the time-based storage range, a GT condition of a table-specific query is defined in a time-based storage range of the table. The GT condition is placed in the head of a query condition. When table-specific queries for the tables are created, a combined query is created by combining all results using the UNION command to integrate all the table-specific queries.

In step (f), a request for the table-specific queries(or a combined query) is sent to the packet information DB after the search queries are generated, a search result is received, and call flow information is re-configured (S460). Since the packet information DB stores substantially all packet flow information until a given time, desired information can be extracted and viewed in any form.

If any aspects of the method for finding packet flow information in real time by dividing a DB and a query have been inadequately described, please refer to the above description of the real-time PISS. Next, a configuration of a PISS according to another exemplary embodiment of the present invention will be described. FIG. 9 is a diagram showing a configuration of a PISS according to another exemplary embodiment of the present invention.

As shown in FIG. 9, the PISS of the present invention includes packet capturing devices 501 each configured with a packet capture unit 510 and a packet information generator 530, a packet information DB 520, and a search query processor 540. Specifically, a packet information DB server 502 can be configured with the packet information DB 520 and the search query processor 540.

The packet capturing device 501 is the same as in the PISS according to the first exemplary embodiment of the present invention. Therefore, its detailed description has already been given.

The packet information DB server 502 divides and manages a plurality of packet information tables 221 with packet flow information such that a real-time search is possible. Specifically, the packet information DB server 502 does not reveal the internally divided packet information tables 221 to an external user, for example, a call- flow search terminal 550. Instead, when the call-flow search terminal 550 creates a query by regarding packet information tables as one DB table and sends a request to the packet information DB server 502, the packet information DB server 502 converts the requested query suitably for an internal table structure, performs a query search, and reconfigures and returns its search results. The search query processor 540 receives a request for a primitive search query

310 for finding packet flow information, creates search queries into which the primitive search query 310 is divided according to packet information tables, sends a packet information search request using the table-specific queries to the packet information DB 520, and returns search results received from the packet information DB 520. For example, the search query processor 540 receives the request for the primitive search query 310 from the VoIP call-flow search terminal 550, etc.

The PISS 500 internally divides the packet information DB into the plurality of packet information tables 221, but does not reveal this internal structure. The structure is only revealed as one packet information table. This is possible since the packet information tables 221 have the same structure. Accordingly, when finding packet flow information, the VoIP call-flow search terminal 550 as the client creates a search query considering one packet information table and sends a query processing request to the PISS 500 of the present invention. The requested search query is the same as the above-described primitive search query 310. That is, the primitive search query 310 is created by regarding the packet information tables 221, into which the packet information DB 220 is divided, as one table. In a query statement of the primitive search query 310, <Table Name> is written as the entire table name.

The search query processor 540 of the packet information DB server 502 creates the table-specific queries 320 into which the primitive search query 310 received from the VoIP call-flow search terminal 550 is divided. Since the creation of the table-specific queries 320 has been described above, its description is omitted here.

The search query processor 540 requests the packet information DB 520 to process the table-specific queries 320 and receives and returns a processing result to the

VoIP call-flow search terminal 550. Since all the packet information tables 331 have the same structure and table-specific queries are combined by a UNION command, the processing result is directly sent to the terminal.

If any aspects of the exemplary embodiment of the present invention described with reference to FIG. 9 have been inadequately described, please refer to the description of the exemplary embodiment of the present invention shown in FIG. 5. When internal processing is performed without exposing a complex internal structure to the client, a program related to a packet information search implemented in the client is simply created and an internal table structure change is free, thereby making maintenance convenient.

On the other hand, when the policy of fixing a GTR length of tables as described above is changed to a policy of flexibly changing the GTR length, a method for computing a GTRs of tables is changed. Even in this case, maintenance may be easy since only related programs of the server should be changed without changing the client programs.

FIG. 10 shows an example of a screen displayed by re-configuring a call flow through found packet flow information according to the present invention.

As shown in FIG. 10, an output screen displays a packet flow between VoIP devices by finding packet flow information based on <Generation Time>, <Source Telephone Number>, and destination Telephone Number>. That is, the screen displays VoIP device-specific requests and responses capable of being viewed at a glance. Through this visualization, each call flow can be easily found and a normal/abnormal state can be easily observed. [Industrial Applicability]

As described above, a system and method for finding packet flow information in real time by dividing a DB and a query according to the present invention can process a call flow state for all packets transmitted from a VoIP network and analyze performance in real time.

A conventional packer analyzer may not analyze all packets in real time due to a limit in processing large- volume packet flow information and limitations of its technical configuration. When all packets are processed, a size of a DB table increases.

However, when the size of data to be processed increases to a certain extent, a processing rate in a database management system (DBMS) rapidly decreases. The present invention addresses the above problems occurring in dividing and processing a table and provides an apparatus and method capable of finding all large- volume packet flow information. Specifically, the present invention can effectively process packets in real time even in the future when VoIP service becomes common and the number of packets is much higher.

A system and method for checking online document issuance according to the present invention can more effectively optimize a search query by dividing a DB table with reference to a packet GT.

The system and method for checking online document issuance according to the present invention can allow a VoIP network manager to directly perform a time- consuming search by storing all packet flow information for a given time and improving a search rate, thereby finding all desired types of packet flow information. In general, when communication materials are stored for 30 days, all states and problems occurring in VoIP communication can be detected and all data required for packet flow information can be stored. Accordingly, all required information can be provided to the VoIP network manager. For example, a match search of part of data is time-consuming, and when packet flow information is large, the search is conventionally impossible in a short time. However, the present invention can process such a search in a short time.

In the system and method for checking online document issuance according to the present invention, a large number of packets are captured in a plurality of packet capturing devices, a DB is generated by extracting only required packet flow information to reduce an information amount, the fundamental packet flow information is mainly managed in a DB server, a related search query is processed in a terminal, and functions are divided to process a large amount of information, thereby using resources more efficiently. The system and method for checking online document issuance according to the present invention can enable a VoIP network provider to detect a call flow in real time, thereby quickly finding a problem and providing its solution when a fault occurs or a request is made due to user inconvenience. Accordingly, the VoIP network provider can maintain and provide a constant service to a user. In the system and method for checking online document issuance according to the present invention, an internal structure of a table divided in a search system server is not externally revealed and a search query is internally processed. Thus, a client terminal can simply create a program related to a packet information search, and more particularly, can create such a program independently of an internal DB table structure of the system, thereby making maintenance convenient.

Claims

[CLAIMS] [Claim 1]

A method for searching packet flow information in real time by capturing all the packets transmitted over a Voice over Internet Protocol (VoIP), the method comprising: (a) configuring a packet information DB with a plurality of packet information tables having the same structure;

(b) capturing and temporarily storing packets transmitted over the VoIP network;

(c) periodically extracting packet flow information from the captured packets, and storing the packet flow information with a capturing time as a generation time (GT) in one of packet information tables in sequence of GTs;

(d) making a primitive search query for packet flow information, the primitive search query regarding the plurality of packet information tables as one table;

(e) making table-specific queries from the primitive search query, each table- specific query corresponding to each of the packet information tables; and

(f) sending a request for the table-specific queries to the packet information DB and acquiring the result of the request.

[Claim 2]

The method of claim 1, wherein in step (a), the packet information tables have the same size, and the number of tables and the table size are determined by the number of packets to be captured, a query processing ability of the DB, and a storing period.

[Claim 3]

The method of claim 1, wherein the packet flow information comprises <Call ID>, <Source Telephone Number>, <Destination Telephone Number>, <Method>, <Telephone Terminal Information^ <Source IP/Port>, and <Destination IP/Port> as the packet flow data extracted from the packets, and further comprises <Generation Time (GT)> as the packet capturing time.

[Claim 4]

The method of claim 1, wherein in step (b), a life-time of packets which are temporarily stored is set to be longer than a period of step (c).

[Claim 5]

The method of claim 1, wherein in step (c), the packet flow information is sequentially stored in the plurality of packet information tables with reference to the generation time, and is cyclically stored from a first table when a last table is full with the current packet flow information.

[Claim 6]

The method of claim 5, wherein in step (e), the table-specific queries are combined by a UNION command.

[Claim 7] The method of claim 6, wherein in step (e), the table-specific query is created for only packet information table in which some parts of generation time ranges (GTRs) are included in a generation time range (GTR) condition of the primitive search query.

[Claim 8]

The method of claim 7, wherein in step (e), a GTR condition in a condition statement of the table- specific query is defined in a range satisfying both the GTR condition within the primitive search query and a GTR of a packet information table to be referred to, and the GTR condition is placed in a head of the condition statement of the table-specific query.

[Claim 9] A system for searching packet flow information in real time by capturing all the packets transmitted over a Voice over Internet Protocol (VoIP), the system comprising: a packet information DB configured with a plurality of packet information tables having the same structure; a plurality of packet capturing devices that capture packets transmitted over the VoIP network, and periodically, extract packet flow information from the captured packets, and store the packet flow information with a capturing time as a generation time (GT) in one of packet information tables in sequence of GTs; and a plurality of call-flow search terminals that make a primitive search query for packet flow information, the primitive search query regarding the plurality of packet information tables as one table, and acquire the request for the table-specific queries by sending the request to the packet information DB. [Claim 10]

The system of claim 9, wherein each of the plurality of packet capturing devices comprises: a packet capture unit that captures and temporarily stores packets transmitted over the VoIP network; and a packet information generator that periodically generates packet flow information extracted from the captured packets, inserts a packet capturing time as a generation time (GT) into the packet information, and stores the packet flow information in the packet information tables. [Claim 11]

The system of claim 10, wherein the packet flow information comprises <Call ID>, <Source Telephone Number>, <Destination Telephone Number>, <Method>, <Telephone Terminal Information^ <Source IP/Port>, and <Destination IP/Port> as the packet flow data extracted from the packets, and further comprises <Generation Time> as the packet capturing time. [Claim 12]

The system of claim 10, wherein the packet information generator sequentially stores the packet flow information in the packet information tables with reference to the generation time, and cyclically stores the packet flow information from a first table when a last table is full with the current packet flow information. [Claim 13]

The system of claim 12, wherein the table-specific queries are combined by a UNION command. [Claim 14]

A system for searching packet flow information in real time by capturing all the packets transmitted over a Voice over Internet Protocol (VoIP), the system comprising: a packet information DB configured with a plurality of packet information tables having the same structure; a plurality of packet capturing devices that capture packets transmitted over the VoIP network, and periodically, extract packet flow information from the captured packets, store the packet flow information with a capturing time as a generation time (GT) in one of packet information tables in sequence of GTs; and a search query processor that receives a request for a primitive search query for a packet flow information, makes table-specific queries from the primitive search query, each table-specific query corresponding to each of the packet information tables, sends a request for the table- specific queries to the packet information DB, and returns the result of the request received from the packet information DB. [Claim 15]

The system of claim 14, wherein each of the plurality of packet capturing devices comprises: a packet capture unit that captures and temporarily stores packets transmitted over the VoIP network; and a packet information generator that periodically generates packet flow information extracted from the captured packets, inserts a packet capturing time as a generation time(GT) into the packet information, and stores the packet flow information in the packet information tables. [Claim 16] The system of claim 14, wherein the packet flow information comprises <Call

ID>, <Source Telephone Number>, <Destination Telephone Number>, <Method>, <Telephone Terminal Information^ <Source IP/Port>, and <Destination IP/Port> as the packet flow data extracted from the packets, and further comprises <Generation Time> as a packet capturing time. [Claim 17]

The system of claim 15, wherein the packet information generator sequentially stores the packet flow information in the packet information tables with reference to the generation time, and cyclically stores the packet flow information from a first table when a last table is full with the current packet flow information. [Claim 18] The system of claim 15, wherein the table-specific queries are combined by a UNION command.