Abstract:
In one embodiment, a method for managing a Voice over IP (VoIP) network includes collecting a first set of data from a first source of network performance management data, each data item in the first set of data corresponding to a call made using the VoIP network; collecting a second set of data from a second source of network performance management data, each data item in the second set of data corresponding to a call made using the VoIP network and being of a different type than the first set of data; correlating the first set of data and the second set of data such that a data item from the first set of data is matched with a data item from the second set of data that corresponds to a common call made over the VoIP network; and outputting a performance report based on the correlating.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates generally to Voice over Internet Protocol (VoIP) networks and relates more particularly to VoIP network maintenance automation. 
         [0002]    In a VoIP network, diagnostics of network performance, reliability, and maintenance may be obtained from a plurality of sources, including, for example, Call Detail Records (CDRs) and Session Initiation Protocol (SIP) signaling data. The existence of these multiple data sources, however, results in a large amount of data that must be reviewed for service assurance, and much of this data may be duplicative (e.g., indicative of common network- or service-related events). In turn, the need to review all of this data may lead to delays in repairing problems in the network. 
         [0003]    Thus, there is a need in the art for a method and apparatus for correlation of data sources in VoIP networks. 
       SUMMARY OF THE INVENTION 
       [0004]    In one embodiment, the present invention is a method and apparatus for correlation of data sources in a Voice over Internet Protocol network. In one embodiment, a method for managing a Voice over IP (VoIP) network includes collecting a first set of data from a first source of network performance management data, where each data item in the first set of data corresponds to a call made using the call detail recording function of the VoIP network; collecting a second set of data from a second source of network performance management data, where each data item in the second set of data corresponds to a call made using the signaling function of the VoIP network, and where a type of the second set of data is different from a type of the first set of data; correlating the first set of data and the second set of data such that a data item from the first set of data is matched with a data item from the second set of data that corresponds to a common call made over the VoIP network; and outputting a performance alert and report based on the correlating. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0005]    The teaching of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which: 
           [0006]      FIG. 1  is a schematic diagram illustrating one embodiment of a system for correlating data sources in a VoIP network, according to the present invention; 
           [0007]      FIG. 2  is a flow diagram illustrating one embodiment of a method for correlating data sources in a VoIP network, according to the present invention; 
           [0008]      FIG. 3  illustrates one example of a SIP text record for an exemplary answered call between VoIP network elements; 
           [0009]      FIG. 4  illustrates one example of a SIP text record for an exemplary blocked call between a call control element and an applications server; 
           [0010]      FIG. 5  illustrates one example of a SIP text record for an exemplary cutoff call between a CCE and an AS; and 
           [0011]      FIG. 6  is a high level block diagram of the data source correlation method that is implemented using a general purpose computing device. 
       
    
    
       [0012]    To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. 
       DETAILED DESCRIPTION 
       [0013]    In one embodiment, the present invention is method and apparatus for correlation of data sources in VoIP networks. Embodiments of the invention correlate two separate sources of VoIP network performance management data, such as CDRs (which are conventionally generated for billing purposes) and SIP signaling data, in order to improve end-to-end network performance capabilities. Synthesis of the data sources allows for the identification of potential network- or service-related events in substantially real time, as well as for the provision of detailed root-cause analyses of these events. 
         [0014]      FIG. 1  is a schematic diagram illustrating one embodiment of a system  100  for correlating data sources in a VoIP network  102 , according to the present invention. As illustrated, the system  100  comprises a call usage collection module  106  and a SIP signaling/call summary module  108 , both of which are coupled to the VoIP network  102 . In addition, both the call usage collection module  106  and the SIP signaling/call summary module  108  are coupled to a correlation engine  110 . 
         [0015]    The VoIP network  102  comprises a plurality of communicatively coupled nodes or network elements  104   1 - 104   n  (hereinafter collectively referred to as “network elements  104 ”) that facilitate the calls between the VoIP network users (e.g., border elements, application servers, network routing engine/call control elements (NRE/CCEs), and customer premise equipment such as customer premise routers). 
         [0016]    The call usage collection module  106  collects CDRs from the network elements  104  and forwards these CDRs to the correlation engine  110 . Similarly, the SIP signaling/call summary module  108  probes the network elements  104  for VoIP signaling protocols and correlates call flows for end-to-end call trace troubleshooting. In other words, the SIP signaling/call summary module  108  collects signaling message data for defect calls over the VoIP network  102 . In one embodiment, defect calls are defined as calls for which the SIP call signaling patterns are abnormal. The SIP signaling/call summary module  108  also provides a text summary of the SIP signaling between the nodes involved in each defect call (on and end-to-end basis) over the VoIP network  102  to the correlation engine  110 . In one embodiment, these text summaries include at least the following for each call: called number (node), calling number, and a time stamp. 
         [0017]    The correlation engine  110  collects and classifies the CDRs and SIP call text summaries relayed by the call usage collection module  106  and the SIP signaling/call summary module  108 . In one embodiment, the correlation engine classifies individual CDRs according to the status of the associated call (e.g., blocked, cutoff, ring/no answer, busy, successful, etc.). In one embodiment, this classification is performed in accordance with an N-field classification rule, where a CDR that satisfies an N-field classification rule is designated as a specific kind of defect (e.g., two fields for CCE CDRs: field one with a value a 1  and field two with a value b 1  indicates a blocked call, field one with a value a 2  and field two with a value b 2  indicates a cutoff call, etc.). These fields may indicate, for example, the direction of a call, the type of a call record, the duration of the call, or among others. In one embodiment, the correlation engine  110  receives SIP call text summaries only for defect calls. In one embodiment, the correlation engine  110  is a concept of one (COO) performance management platform, such as a performance management operation support system (PMOSS). 
         [0018]    Based on the classification of the CDRs and SIP call text summaries, the correlation engine  110  correlates the defect CDRs and SIP call text summaries. In particular, the correlation engine  110  correlates the CDRs and SIP call text summaries for all calls in which either the CDR or the call text summary is classified as a “defect,” as discussed above. For instance, CDRs that correspond to the same pair of called/calling numbers in a given window of time may be grouped together. Subsequently, SIP call text summaries for the same pair of called/calling numbers in the same window of time may be correlated with the group of CDRs. As a result, a CDR corresponding to a given call made over the VoIP network  102  is matched with a SIP call text summary for the same call. In one embodiment, correlation is based on at least one of the following for each call: calling number, called number, time stamp, and the IP addresses and ports of media and/or signaling nodes. In one embodiment, a sliding time window of configurable width is examined for matching calling/called number pairs in a given time interval. 
         [0019]    In one embodiment, troubled pairs of nodes  104  are identified by analyzing SIP signaling call tests. The CDRs are then analyzed to identify the root cause of the defect call. Having correlated the defect CDRs and SIP call text summaries, the correlation engine  110  then generates and outputs (e.g. to a display or to a human operator) performance alerts and reports  112 , where performance alerts and reports  112  are based on correlated CDR and SIP call text summary data. In one embodiment, the performance alert output contains one or more performance alerts, which are generated in substantially real time for network impacting events. The performance report output comprises consolidated CDR/SIP signaling data and provides an enhanced end-to-end call view including intermediate nodes that might otherwise not be caught through examination of the CDRs or the SIP signaling data individually. The performance alerts may, in turn, be used to generate trouble tickets indicative of errors in the VoIP network  102 . An advantage of the present invention is that a single trouble ticket can be generated for a given event, where the single ticket includes both a view of the event as seen by the network elements  104  (i.e., as seen through the CDRs) and a view of the event that is independent of the network elements  104  (i.e., as seen through the SIP signaling data). 
         [0020]    The system  100  therefore provides end-to-end performance reporting, substantially real time performance surveillance, and network management controls for the VoIP network  102 . 
         [0021]      FIG. 2  is a flow diagram illustrating one embodiment of a method  200  for correlating data sources in a VoIP network, according to the present invention. The method  200  may be implemented, for example, by the system  100  illustrated in  FIG. 1 . As such, description of the method  200  will make reference to several of the system components described above; however, it is to be understood that the method  200  is not limited to execution with the system  100 . 
         [0022]    The method  200  is initialized at step  202  and proceeds to step  204 , where the call usage collection module  106  and the SIP signaling/call summary module  108  monitor the network elements  104  of the VoIP network  102 . In step  206 , the call usage collection module  106  collects CDR data from the network elements  104 ; similarly, in step  208 , the SIP signaling/call summary module  108  collects SIP signaling and call summary data from the network elements  104 . 
         [0023]    In step  210 , the correlation engine  110  analyzes the CDRs collected by the call usage collection module  106 ; similarly, in step  212 , the correlation engine  110  analyzes the SIP signaling and call summary data collected by the SIP signaling/call summary module  108 . In one embodiment, step  210  involves the further step of identifying “defect” CDRs, as discussed above. In one embodiment, step  212  involves analyzing “defect” SIP signaling and call summary data (e.g., data associated with calls for which the SIP call signaling patterns are abnormal). 
         [0024]    In step  214 , the correlation engine  110  correlates the “defect” CDRs and the SIP signaling and call summary data for all calls in which either the CDR or the call text summary is classified as a “defect,” as discussed above. In one embodiment, correlation first involves identifying troubled pairs of nodes based on the SIP signaling and call summary data. Having identified a troubled pair of nodes, the root cause of the trouble is then identified based on the CDRs. For example, a group of CDRs may indicate that a certain switch in the VoIP network  102  observed one thousand blocked calls in a span of fifteen minutes. Correlated SIP signaling data may indicate that all of these blocked calls originated from the same VoIP network element. 
         [0025]    The correlation engine  110  then generates and outputs performance alerts and reports based on the correlated data, as discussed above. The method  200  then returns to step  204  and proceeds as discussed above to monitor the network elements  104 . 
         [0026]      FIGS. 3-5  illustrate the layouts of exemplary SIP text records that may be used in the correlation of VoIP network data sources, according to embodiments of the present invention. Specifically,  FIGS. 3-5  represent examples of text summaries of the SIP signaling between network elements that may be generated by the SIP signaling/call summary module  108  of  FIG. 1 , as discussed above. 
         [0027]    In particular,  FIG. 3  illustrates one example of a SIP text record  300  for an exemplary answered call between two VoIP network elements;  FIG. 4  illustrates one example of a SIP text record  400  for an exemplary blocked call between a call control element (CCE) and an applications server (AS); and  FIG. 5  illustrates one example of a SIP text record  500  for an exemplary cutoff call between a CCE and an AS. In  FIGS. 3-5 , spaces and line breaks are included for clarity; embodiments of the invention generate actual SIP text records on single lines without spaces. In some embodiments of the invention, the SIP text records also include the signaling between other network elements for the call (e.g., Internet Protocol border elements (IPBEs) and network gateway border elements (NGBEs)). 
         [0028]      FIG. 6  is a high level block diagram of the data source correlation method that is implemented using a general purpose computing device  600 . In one embodiment, a general purpose computing device  600  comprises a processor  602 , a memory  604 , a data source correlation module  605  and various input/output (I/O) devices  606  such as a display, a keyboard, a mouse, a modem, and the like. In one embodiment, at least one I/O device is a storage device (e.g., a disk drive, an optical disk drive, a floppy disk drive). It should be understood that the data source correlation module  605  can be implemented as a physical device or subsystem that is coupled to a processor through a communication channel. 
         [0029]    Alternatively, the data source correlation module  605  can be represented by one or more software applications (or even a combination of software and hardware, e.g., using Application Specific Integrated Circuits (ASIC)), where the software is loaded from a storage medium (e.g., I/O devices  606 ) and operated by the processor  602  in the memory  604  of the general purpose computing device  600 . Thus, in one embodiment, the data source correlation module  605  for correlating data sources in a VoIP network described herein with reference to the preceding Figures can be stored on a computer readable medium or carrier (e.g., RAM, magnetic or optical drive or diskette, and the like). 
         [0030]    It should be noted that although not explicitly specified, one or more steps of the methods described herein may include a storing, displaying and/or outputting step as required for a particular application. In other words, any data, records, fields, and/or intermediate results discussed in the methods can be stored, displayed, and/or outputted to another device as required for a particular application. Furthermore, steps or blocks in the accompanying Figures that recite a determining operation or involve a decision, do not necessarily require that both branches of the determining operation be practiced. In other words, one of the branches of the determining operation can be deemed as an optional step. 
         [0031]    While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.