CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation-in-part of U.S. patent application Ser. No. 09/188,680 filed on Nov. 10, 1998 entitled INTERCONNECT TRAFFIC ANALYSIS, which is a continuation-in-part of U.S. patent application Ser. No. 09/048,102 filed on Mar. 26, 1998 entitled NETWORK PLANNING TRAFFIC MEASUREMENT PROGRAM, the disclosures of both of which are entirely incorporated herein by reference.

TECHNICAL FIELD

The present invention relates to methods and systems for analyzing call specific data records for interconnect traffic between different carriers' portions of a telecommunication network, in order to allow one carrier to analyze the customer base and traffic patterns of the other carrier.

Acronyms

The written description uses a large number of acronyms to refer to various services, messages and system components. Although generally known, use of several of these acronyms is not strictly standardized in the art. For purposes of this discussion, acronyms therefore will be defined as follows:

Address Complete Message (ACM)

Asynchronous Digital Subscriber Line (ADSL)

ANswer Message (ANM)

Automatic Message Accounting (AMA)

Call Detail Record (CDR)

Calling Party Number (CPN)

Carrier Identification Code (CIC)

Centi-Call Seconds (CCS)

Central Office (CO)

Competitive Local Exchange Carrier (CLEC)

Common Channel Interoffice Signaling (CCIS)

Common Language Location Identifier (CLLI)

Customer Record Information System (CRIS)

Destination Point Code (DPC)

End Office (EO)

Global Title Translation (GTT)

Initial Address Message (IAM)

Integrated Services Digital Network (ISDN)

ISDN User Part (ISDN-UP or ISUP)

Inter-exchange Carrier (IXC)

Internet Service Provider (ISP)

Landing Zone (LZ)

Line Identification DataBase (LIDB)

Local Area Network (LAN)

Local Exchange Carrier (LEC)

Loop Maintenance Operations Systems (LMOS)

Message Signaling Unit (MSU)

Message Transfer Part (MTP)

Minutes of Use (MOU)

Mobile Switching Center (MSC)

Multi-Dimensional DataBase (MDDB)

Numbering Plan Area (NPA)

Online Analytical Processing (OLAP)

Origination Point Code (OPC)

Operations, Maintenance Application Part (OMAP)

Personal Communication Service (PCS)

Personal Computer (PC)

Private Branch Exchange (PBX)

Public Switching Telephone Network (PSTN)

Regional Bell Operating Company (RBOC)

Release Complete Message (RLC)

Release Message (REL)

Service Switching Point (SSP)

Signaling Link Selection code (SLC)

Signaling System 7 (SS7)

Signaling Point (SP)

Signaling Transfer Point (STP)

Structured Query Language (SQL)

Subsystem Number (SSN)

Transaction Capabilities Applications Part (TCAP)

Wide Area Network (WAN)

BACKGROUND ART

Recent legislative and regulatory changes have created a more open service provider environment in the telecommunications industry. In this new environment, more and more companies are offering local exchange services as competitive local exchange carriers (CLECs), that is to say, entering the local market in direct competition with the Regional Bell Operating Company (RBOC) or independent company serving as the incumbent local exchange carrier (LEC). The LECs also face competition in a number of other forms. For example, many wireless services compete with the LEC, at least to some extent. Also, many large corporations operate their own private networks, which siphons off business traffic that otherwise would pass through a LEC's network.

A CLEC, for example, may lease certain unbundled elements of the LEC's network at reduced rates for resale. The CLEC may lease an unbundled port on an end office switch, as a point of access to the LEC's switch and the subscriber loops. The CLEC then connects its own switch network to the unbundled port. Alternatively, the CLEC may operate its own independent switching facilities and loop plant. In either case, the regulatory requirements mandate that the CLEC facilities must be integrated into the public switching telephone network (PSTN) in a seamless manner from the customer's perspective. As such, the customers must be able to make and receive telephone calls using existing dialing patterns, without any apparent distinction in processing as a result of service through the CLEC. The regulatory environment therefore places certain burdens on the incumbent LEC, to provide an efficient interconnection to the CLEC's facilities and to provide mechanisms for compensation between the parties for calls interconnected between the two carriers' networks.

A cellular service provider typically operates a number of switching offices referred to as mobile switching centers (MSCs). The MSCs connect to offices of the LEC network, for local services. The MSCs also connect to a point of presence of an IXC, for long distance and international services. Each MSC connects to a number of base stations. The base stations provide two-way radio communications with wireless stations of the customers. Today, most of the wireless stations are mobile stations, however, a number of cellular service providers are now offering wireless service to fixed locations. A transceiver at the fixed location provides the wireless communications with one of the base stations and provides an on-premises interface to the customer's telephone wiring. To the customer's telephone equipment, the interface often appears like a normal telephone line from the LEC. This fixed location service is sometimes identified as a “wireless loop” or “wireless drop” service.

Many large businesses operate private networks. In such a case, the business entity owns and operates one or more private branch exchanges (PBX). These exchanges may connect to offices of a LEC or CLEC, but only for local off-net traffic. The business usually contracts with an interexchange carrier (IXC), both for trunk circuits between the business' private exchanges and for long distance and international telecommunications services. The private exchanges connect directly to the IXC's equipment and bypass the local carriers.

Interconnect Traffic is generally defined as any calls which are routed and “handed-off” from one carrier to another. This may take the form of Independent, Interexchange Carrier, or Cellular service providers directing traffic to or receiving traffic from a local switch of the LEC. Typically, the LEC must provide tandem capacity and trunking to one or more exchanges of any of these other carriers, to carry the interconnect traffic between the carriers' networks.

Providing this capacity to the other carriers places certain burdens on the LEC. The other carriers, however, actually use this capacity in no small part to take business away from the LEC. The CLEC is a direct competitor, who attempts to design his business plan to take as much premium traffic as possible from the LEC. The cellular providers' wireless loop services also are a form of direct competition. In addition, the sale of many mobile services helps to depress sales of a number of services by the LEC, such as second line services. Finally, the bypass of the LEC by the IXC in cooperation with private networks places the IXC in competition with the LEC for interconnection to the private networks. The interconnection traffic, particularly to large businesses, often is one of the most profitable classes of local telephone service.

For revenue prediction purposes and for purposes of regulatory proceedings, the incumbent LEC tries to determine the erosion of its customer base by the business practices of its competitors. At present, the incumbent LEC has no way to determine the total market “actuals” of the customer base of any of the other potentially competing carriers. The LEC also has no way to track or forecast market gains by the other carriers. Incumbent local service providers today are in an unfortunate position where they are unable to effectively determine the magnitude of their own losses to these various forms of competition.

A number of techniques have been developed for monitoring operations of the public switching telephone network. While these prior techniques may be effective for some purposes, they have not proven effective for analyzing a competitor's traffic. To complete the understanding of the background of the invention, it may be helpful to briefly consider some of the prior techniques for network monitoring.

U.S. Pat. No. 5,475,732 Pester describes an SS7 Network Preventative Maintenance System for detecting potential SS7 and switched network troubles, automatically analyzing the troubles, and providing alarm and corrective action to avoid major network events. The Pester SS7 Real Time Monitor System described in that Patent is a multi-stage SS7 network preventative maintenance tool that traps SS7 messages, detects potential SS7 and switched network troubles, automatically analyzes those troubles, and provides alarm and corrective action instructions to maintenance personnel.

U.S. Pat. No. 5,592,530 to Brockman et al. relates to an SS7 monitoring system for evaluating the operations of telephone switches by capturing data between signaling nodes of a telephone switching system. The Brockman et al. surveillance equipment captures signaling information from different signaling network paths within a mated pair of signaling transfer points (STPs) pair and correlates the fragmented messages for each monitored call. The system is capable of generating call detail records from the SS7 messages of a mated pair cluster, for use in billing and fraud detection.

While the above discussed Pester and Brockman et al. Patents describe the usefulness of monitoring an SS7 common channel interoffice signaling network for event detection, neither of these patents is directed to the particular problems of traffic measurement addressed by the present invention. The Pester Patent places emphasis on monitoring of the SS7 network itself in order to detect troubles in its functioning. The Brockman et al. Patent focuses on monitoring of all links to the STPs in a pair and the assembly of related SS7 signaling messages to form a record of call completions.

While these methodologies may be effective for their stated purposes there remains a distinct need for an efficient and effective tool for monitoring and analyzing competitors' traffic, for example, as it passes between the LEC's network and the networks of the different carriers. Attempts to use other more traditional approaches, such as the accumulation of data from the switches themselves and the Engineering and Administrative Data Acquisition System fell short of providing the desired information.

For example, today, a LEC might attempt to measure bypass traffic by counting the number of customer orders for disconnection from the LEC's network. These orders, termed “disconnects,” provide information as to lost customers. However, the disconnect data does not specifically identify what alternate carrier if any that the disconnected customers selected.

A need exists for an effective technique to measure traffic passing between two potentially competing networks, particularly between a network of a LEC and a network operated by another, potentially competing, carrier. More specific needs call for a technique to measure such traffic so as identify the size of the other carrier's customer base and to analyze patterns of the other carrier's traffic.

It is accordingly an object of this invention to provide a relatively low cost solution to the problems outlined above.

It is another object of the invention to provide a timely, powerful, cost effective means of analyzing traffic on one carrier's Public Switched Telephone Network (PSTN), to accurately analyze traffic of another carrier's network. This information can provide valuable inputs to company forecasting and network capacity management systems.

It is an object of one aspect of the invention to provide a traffic analysis tool to enable a carrier to process data regarding traffic through the carrier's network to estimate the customer base of another carrier.

It is a further object of another aspect of the invention to provide a traffic analysis tool to enable a carrier to process data regarding traffic through the carrier's network to distinguish different types of service provided to customers within another carrier's network.

DISCLOSURE OF THE INVENTION

To meet the above stated needs and objectives, the invention provides effective techniques for tracking traffic through a telecommunication network in such a manner as to enable one carrier to analyze a competitor's traffic, particularly to the extent that the traffic passes through the one carrier's network. Aspects of the invention encompass both methods and systems for accumulating the necessary call data from monitoring of the network and analysis of the call data with regard to the competitor's traffic.

The call records are developed from monitoring or compiling of items of information from certain management data messages used by one or both of the carriers' networks. Management data here refers to information generated by the telecommunication network for its operations purposes, for example, interoffice signaling messages generated to control call set-up and tear-down. Another example of such data would be messages sent from central offices of the network to an accounting office, for record keeping and billing purposes.

Thus, a first aspect of the invention relates to methods of analyzing records of interconnect traffic to identify customers of a competing carrier. Such methods involve capturing management data messages communicated by a first carrier's telecommunication network during processing of calls associated with a second carrier's telecommunication network, over a predefined study period. During the study, a record of each of a number of calls interconnected between the two carriers networks are compiled from the captured messages. The methods also involve compiling a list of addresses of customers of the second carrier's network, from the records of the calls.

Another aspect of the invention relates to distinguishing different types of services offered through the second carrier's network. This method invention involves processing the call detail records, to derive aggregate traffic data for calls to or from network identifiers associated with customers of the competing carrier. The aggregate traffic data is analyzed to form a list of network identifiers having aggregate traffic exhibiting a pattern associated with a particular type of service.

This aspect of the invention encompasses recognizing a variety of different patterns, for example relating to a high number of incoming calls, with little or no outgoing traffic. This pattern corresponds to hunt groups used by Internet Service Providers (ISPs) and to voice hunt groups. The patterns for these two services may be distinguished, however, because an ISP hunt group exhibits a long average hold time, whereas the voice hunt group exhibits a relatively low average hold time.

The invention also enables reciprocal compensation billing assurance. This advanced analysis of usage characteristics of a CLEC will help reveal possible access fraud going on between an incumbent LEC and a CLEC. Local interconnection agreements between an incumbent LEC and CLEC specify different billing rates for “local” and “access” calls. The interstate or access terminating usage rates are typically significantly greater than local usage rates, as defined in the reciprocal compensation billing arrangements between the carriers. Measurements of the CPN (Calling Party Number) contained in the call detail records can be used as a reliable method to validate the jurisdictional nature of interconnect traffic. It is important to note that CPN values ordinarily are provided on all calls in digital SS7 switching systems, with the exception of PBXs served with analog trunking. CPN can however be surpressed for an individual line (as a paid for privacy feature), for a trunk group level, and for an entire switch. CPN is not normally blocked because such blocking violates interconnect agreements to provide the data for billing validation and impacts the operation of Calling Line Identification customer services and E

911

. Unfortunately, many CLEC's consistently provide a very low percentage of CPN on their interconnect traffic. As a result, incumbent LECs are in many cases forced to “trust” that the traffic is local on their monthly billing statements without CPN to effectively validate.

In accord with the invention, measurement and analysis of CPN data from CLECs provides an indication of the assurance level of the distinctions between local and access calls reported for reciprocal compensation billing purposes. Using the calling characteristics on the interconnect traffic, a profile of the CLEC, its customer base, and traffic type can be built. For example, through thresholding and exception analysis, an incumbent LEC can identify a traffic pattern that points to call volumes that did not originate in the CLEC's switch. For example, very high originating local usage volumes may not be feasible from a switch with a defined number of access lines. If this usage has no corresponding CPN to validate the local nature of the calls, it suggests that some portion of the calls were not originated in that local switch. This tandem routed traffic may itself violate local interconnect agreements and more importantly, could reveal access traffic that should be routed through the incumbent LECs access tandem switch.

In an actual public network, all calls between two carriers' networks are interoffice calls. The preferred embodiments of the present invention utilize real time monitors on selected common channel interoffice signaling links to collect messages relating to set-up and tear-down of interconnect calls. A site processor compiles data from the interoffice signaling messages relating to individual calls, to form call detail records (CDRs) for interconnect call attempts. The site processor uploads the CDRs to a central server. The server maintains a relational database for the CDRs derived from the signaling data.

Data from the relational database is processed or ‘prepared’ and uploaded to a multi-dimensional database. The data preparation includes supplementing the records with reference data and, where necessary, spreading or “binning” usage data to multiple tracking intervals. The multi-dimensional database provides on-line analytical processing tools for enhanced processing of the call data and offers an efficient graphical user interface. The user interface may be a client-server interface, but preferably the multi-dimensional database provides a web suite type interface.

Applications running in the multi-dimensional database enable analysis and presentation of study results. Such applications might include an application to derive an up-to-date list of the network identifiers associated with customers of the competing carrier. Repeated execution of the collection and application over subsequent study periods allows the carrier to determine changes in the competing carrier's customer base. For example, if the competing carrier provides local landline telephone services, the application would provide an estimate of the number of telephone subscribers, the number of subscribers added by the competitor since the previous study and the number of subscribers lost since the previous study. Another application might distinguish the different types of services, e.g. by identifying different hunt groups and estimating the number of lines in each identified hunt group. Knowledge of the number of customers together with an estimate of the number of lines in multi-line groups such as hunt groups provides an estimate of the overall number of lines provided to customers by the competing carrier.

Additional objects, advantages and novel features of the invention will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention. The objects and advantages of the invention may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawing figures depict the present invention by way of example, not by way of limitations. In the figures, like reference numerals refer to the same or similar elements.

FIG. 1

is a simplified process flow chart helpful in understanding the interconnect traffic analysis to estimate levels of a competitor's business, in accord with the present invention.

FIG. 2

is a simplified process flow chart providing a general illustration of a process enabling one carrier to analyze and distinguish certain types of service provided by another carrier, in accord with an embodiment of the invention.

FIG. 3

is a simplified process flow chart depicting a process for identifying and analyzing a specific type of traffic through the other carrier's network, such as that to an Internet service provider.

FIG. 4

is a block diagram showing the high-level functional aspects of a traffic track system for analysis of carrier interconnect traffic.

FIG. 5

is a block diagram illustrating a switched telephone network and elements used to capture and analyze call data from that network to implement traffic analysis applications in accord with the invention.

FIG. 6

illustrates in graphic form the layout of an SS7 protocol interoffice signaling message.

FIG. 7

graphically depicts the layout of the routing label portion of the SS7 message of FIG.

5

.

FIG. 8

is a flow chart illustrating the high-level process of overall management of a traffic track study, such as a traffic study to quantify the number of lines or the like served through another carrier's network.

FIG. 9

is a flow chart useful in explaining the operations involved in data preparation in the traffic track system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention involves compiling call records from management data of a telecommunication network. Management data here refers to information generated by the telecommunication network for its operations purposes, for example, messages sent from central offices of the network to an accounting office, for record keeping and billing purposes. The preferred embodiments for analysis of interconnect traffic between carriers compiles the detailed call records from interoffice signaling messages generated to control call set-up and tear-down. From the detailed call records, the invention provides tools to analyze the interconnect traffic and provide estimates regarding a competing carrier's business.

Generally, calls routed and “handed-off” from one carrier to another make up interconnect traffic. This may take the form of Independent, Interexchange Carrier, or Cellular service providers directing traffic or receiving traffic from a local exchange carrier's switch. The inventive analysis covers virtually any interconnect traffic crossing the interface between two carriers' networks, for the purpose of monitoring and analysis of the bypass, competitive access line growth and related competitive services.

Specifically, the present invention involves analysis of the detailed records of interconnect calls, to allow one exchange carrier or network service provider to estimate relevant statistics regarding aspects of another carrier's competing business. One particular analysis of the call detail records allows the one carrier to identify network addresses, e.g. the telephone numbers, of the other carrier's customers. The total number of addresses of the other carrier provides an indication of the size of the other carrier's customer base. Changes in the active customer addresses indicate losses or gains by the other carrier.

It is also possible to analyze the detailed records of interconnect calls, to distinguish between different types of traffic or service offered by the potentially competing carrier. For example, often a business utilizes one number for incoming calls to a hunt group. It is possible to identify hunt groups from analysis of the volume of incoming traffic to specific numbers. One particularly useful application of this technique identifies lead telephone numbers for hunt groups utilized by Internet Service Providers (ISPs). Having identified the lead telephone numbers of the hunt groups, it is possible to estimate the number of lines within each of the hunt groups based on cumulative usage data from the detailed records.

The traffic tracking techniques of the present invention may provide either carrier a view of the traffic across the interface. For example, an IXC, a CLEC or a cellular service provider could monitor signaling and compile the detailed call records for analysis of a LEC's traffic. For purposes of further discussion, however, assume that the LEC chooses to implement the traffic tracking system.

In the context of a landline competitor, the competitor analysis methodology identifies the number of access lines served by a CLEC connected to the LEC network. In general, CLEC access lines are identified using the following process:

a) Call Detail Records of interconnect traffic for a given period are captured.

b) A data processing application captures CLEC numbers from the CDRs, including

(1) CLEC Calling Numbers for CLEC originating calls; and

(2) CLEC Called Numbers for LEC originating calls.

c) A cumulative list of numbers is kept for each CLEC studied.

d) The application also finds hunt groups, particularly ISP hunt groups.

e) The application implements a model to convert hunt group usage information to an estimate of the number of members in the hunt group. Hunt groups over a given size are assumed to use DS

1

service.

f) Measurements of CLEC traffic preferably are taken monthly. New access line numbers appearing in the traffic are assumed to be gain. If numbers did not appear in the data for the latest month, they are considered as loss.

Almost all numbers in a CLEC network will either receive or generate at least one interconnect call in the measurement period. The CDR data from monitoring interconnect traffic therefore will include at least one CDR for virtually every number used by the CLEC's customers. The percent of customer stations that will not make or receive such calls during the given period is small, can be estimated, and is reasonably stable. The DS

1

and higher rate access lines can be distinguished from lower rate lines (e.g. DS

0

lines) through analysis of call characteristics, such as peak hour connect time.

FIG. 1

shows one embodiment of a high-level process flow involved in analysis of competitive traffic conditions, in accord with the invention. The carrier seeking to analyze a competitor's traffic, such as an incumbent LEC, deploys a monitoring and data processing system, as discussed in more detail later. Using this system, at step S

1

the carrier collects call detail records (CDRs), relating to all interconnect traffic between the LEC's network and the competing carrier's network for some predefined study period. The LEC can actually obtain the CDR data from monitoring of operations of its own network.

For each call interconnected between the two carriers' networks, the CDRs provide considerable information. The CDR information preferably includes at least the calling party telephone number and called party telephone number, the time of the call, whether or not completed, and the duration of the call if completed. For each call, one of the two numbers represents a number serviced through the competing carrier's network. In accord with one aspect of the invention, the CDRs are processed to accumulate numbers used by the competing carrier's customers, as an indication of the size of that carrier's active customer base.

In the process of

FIG. 1

, the competing carrier's customer number from each CDR is analyzed and compared to a list L

1

of known numbers associated with the competing carrier. Typically, the list L

1

is compiled and maintained through earlier operations of the process of FIG.

1

.

The second step of the process (S

2

) is selection of a first CDR for processing. The selected CDR provides a number (calling party or called party) of a customer served by the competing carrier's network. The process next involves checking the list L

1

to determine if the number from the selected CDR is a new number (S

3

) or if it is already in the list. If the number is new, processing in step S

3

branches to step S

4

, in which the number from the selected CDR is added to a list of new numbers. At S

3

, if the number is in the list L

1

, processing branches to step S

5

, essentially skipping over step S

4

.

In step S

5

, the processing branches based on whether the currently selected CDR is the last CDR in the data collected for the current study. If not, processing branches to step S

6

for selection of the next CDR from the study data. After selection of the next CDR, processing continues again with step S

3

to determine whether or not the competing carrier's number in the next CDR is new and if so add that number to the list of new numbers (S

4

). Essentially, steps S

3

to S

6

form a loop that sequentially processes all of the CDRs collected in step S

1

for purposes of the current study. When the process loop completes processing of the last CDR, step S

5

recognizes this condition, and at this point, the list L

2

of new numbers is complete for the current study.

The process of

FIG. 1

also involves analysis with regard to activity related to known numbers already contained in the competing carrier's list L

1

. Thus, in step S

7

, the process sorts the previously known list of numbers L

1

based on usage. Specifically, this step involves analysis of the usage data in the CDRs collected in step S

1

, to cull out a list L

3

of old numbers not used during the current study period.

Those numbers from the list L

1

having some usage activity in the current study period are supplied to a merge operation (S

8

), which merges those numbers with the new numbers in the list L

2

to form an updated list L

1

′ of known active numbers. The various lists L

1

′, L

2

, L

3

are available for statistical analysis (S

9

). The updated list L

1

′, for example, provides an indication of the competing carrier's customer base during the study period. The list of new numbers L

2

is an indication of customer gain, whereas the list of unused numbers L

3

may represent customers taken out of service with the competing carrier.

The analysis (S

9

) preferably entails analysis of usage data and traffic patterns. Analysis of usage and traffic patterns for the current period utilizes the newly collected CDRs (D

1

). The analysis may compare results from those CDRs and/or the current lists to archived information (D

2

), to show incremental changes and long term trends apparent from the interconnect traffic.

The analysis can provide a relatively high level overview, such as the size of and changes in the customer base indicated by the telephone number lists and the levels of interconnect usage. In the preferred embodiments, the monitoring system collects the CDRs from interoffice signaling messages, and the resulting CDRs contain considerable additional information. The analytical processing of such CDRs enable the LEC or other carrier conducting the study to identify traffic patterns, and in some cases at least, to distinguish different types and levels of service provided by the other carrier from the traffic patterns.

One class of distinction of particular interest relates to commercial customers utilizing multiple line services, such as hunt groups. Many businesses utilize one number for all incoming calls to the lead number of a group of lines, referred to as a hunt group. ISPs, in particular, utilize hunt groups for all of their Internet access traffic. The hunt groups of ISPs exhibit no outgoing traffic. The different types of customer, business as opposed to residential or even ISP as opposed to other businesses, have different forecasts for impact on the carrier's network and projected revenues. Using the inventive analysis, the carrier effectively can project the amount of revenue that might have been generated had the business traffic remained on the carrier's network, the limited revenue produced by the interconnect traffic, and thus the loss caused by migration of the business traffic to the competing carrier.

The discrimination between different types of services or customers involves compiling and analyzing call traffic data, to recognize patterns of calls to and/or from certain types of users. In particular, this involves searching for patterns of calls to a certain, limited number of destination telephone numbers and identifying the numbers based upon recognition of the appropriate calling pattern. Depending on the type of user, the pattern may vary. For an ISP, for example, the calling pattern involves a high volume of incoming calls and a long average hold time. If the pattern is consistent with ISP access, there will be no outgoing traffic from a number assigned to an ISP. Other businesses may exhibit high volumes of both incoming and outgoing calls. If the call traffic is predominantly voice traffic, the average hold times will be relatively short.

FIG. 2

depicts the high-level process flow of a method for distinguishing different types of subscriber telephone service numbers within the competing carrier's network, for example to distinguish hunt group numbers from residential telephone numbers. Again, the process relies on a system for monitoring certain management data messages used by the network. This system compiles detailed records in the form of CDRs for interconnect calls carried across the interface between the two carriers' networks (S

21

). The CDRs may relate to all calls interconnected between the networks, to calls connected from the carrier's network and terminating into the competing carrier's network, or to calls connected from the competing carrier's network for termination in the carrier's own network.

The detailed call records are processed to create relevant summary information characterizing the call traffic through the selected portion of the network (S

22

). For example, at this point, the summary data will indicate the number of calls to each destination number as well as the time and duration for each call interconnected between the two networks.

The routine then executes a series of steps to filter the information based on call statistics relative to the users' telephone numbers. This filtering progressively narrows down the set of numbers under consideration until a collection or subset of numbers is developed, where all the numbers collected in the remaining subset exhibit traffic statistics satisfying all of the filter criteria. The carrier's technician selects the filter criteria for a particular study in order to cull out numbers corresponding to a particular traffic pattern associated with a particular type of customer or a particular type of service that the competing carrier might offer.

The filtering often utilizes one of several different measures of usage, such as minutes of use (MOU), centi-call seconds (CCS) or peg count. CCS is a measure of connect time similar to MOU but based on units of one hundred seconds of call duration. Peg count is the number of calls.

In one example, to distinguish hunt group numbers from numbers for residential or other services, the routine would first filter the numbers based on volume of incoming call traffic. The lead number of a hunt group typically will have a large number of incoming calls (peg count) directed to that number. In step S

23

, the routine filters the data associated with destination telephone numbers in the competing carrier's network based on the volume or number (peg count) of incoming calls counted in the study period. This filter operation may select some arbitrary number of destinations having the highest incoming call volumes, e.g. the top fifteen. Preferably, the processing in step S

23

identifies all numbers associated with a volume of incoming calls meeting or exceeding a threshold. If the intent is to ultimately identify hunt group numbers, data relating to destination numbers having a relatively low volume of incoming calls (typically residential or small business) may be discarded.

From the numbers identified in step S

23

, the process may now execute one or more additional filtering steps (S

24

) with respect to other parameters corresponding to the pattern for the type of service or customer of interest. The routine analyzes aggregate traffic data for the telephone numbers collected after all of the filter operations (S

25

). Of particular interest, this analysis can determine the number of lines associated with a particular telephone number.

The number of lines or DS

0

channels can be determined by analysis of the traffic carried during any period in which a hunt group is overflowing, as indicated by numbers of uncompleted calls caused by user busy conditions. If the maximum capacity were not reached during the study period, the busiest hour would be the best choice. Some general assumptions might be reasonable. For example, it might be assumed that ISP hunt groups will be busiest during the “ISP busy hour.” In contrast, it might be assumed that Voice/PBX Trunk hunt groups will be busiest during the “Voice Busy Hour”, i.e. that hour in which non-ISP traffic is busiest.

For hunt group lines, the lead number used on incoming call is associated with calls ultimately terminated on more than one line in the group. A normal telephone line can only support so much usage per hour or other unit of time, whereas a group of lines can support a higher average amount of connect time per hour. Thus, to identify multi-line hunt groups, the routine accumulates data regarding usage within each hour. The filter parameter could relate to average usage over the time period, but preferably the filter parameter in step S

24

relates to peak hour connect time. In step S

24

, peak hourly connect times in CCS, for the numbers remaining after step S

23

, are compared to a threshold value. Again, data relating to telephone numbers not satisfying the criteria, i.e. having a relatively low peak hourly connect time, may be discarded.

At this point, the first two filter steps (S

23

, S

24

) have culled the data down to identify a list of those numbers satisfying the criteria for high volume and high peak hourly connect times. Depending on the level of accuracy desired, this list of candidate numbers may actually be sufficient. However, the procedure may go through another filter operation, related to other criteria.

The statistical filtering produces a list numbers satisfying the filter criteria. However, the collected CDRs for the traffic relating to those numbers collected for the study are available for further analysis. One analysis operation of particular interest involves estimation of the number of lines in each group (S

25

). For example, if connected time is measured as Centi-Call Seconds (CCS), the threshold for recognizing a multi-line group might be 36 CCS in the peak hour. For estimating the number of lines in the group, the processing routine would divide the CCS value for the peak hour by 36. For example, for a peak hour usage of 360 CCS associated with one lead number, there must be at least 10 lines in the group, and the routine might estimate that there actually are 10-12 lines in the particular group. Groups estimated at 24 lines or higher are assumed to use DS

1

service from the CLEC.

The traffic pattern analysis can distinguish a number of different types of customer access lines within the CLEC's network. Examples of line types and corresponding traffic pattern parameters include:

a) DS

1

Level Access:

1. ISP Hunt Groups: High Number of Calls, High Connect Time, Long Average Hold Time, Incoming Traffic Only

2. Voice Hunt Groups: High Number of Calls, High Connect Time, Short Average Hold Time, Incoming Traffic Only

3. PBX Trunks: High Number of Calls, High Connect Time, Short Average Hold Time, Incoming and Outgoing Traffic

b) Below DS

1

Level Access:

1. Key System Trunks: Medium Number of Calls, High Connect Time, Short Average Hold Time, Incoming and Outgoing Traffic

2. Business Lines: Low Number of Calls, Medium Connect Time, Short Average Hold Time, Incoming and Outgoing Traffic

Individual lines preferably are identified by number and ranked or grouped according to traffic characteristics, e.g. daily minutes of use. The total quantity of individual numbers can be counted, and an average usage per day determined for each day measured.

To understand application of the analytical technique to distinguish access lines, it may be helpful to consider a specific example. One example of a specific business using multi-line hunt groups that is of particular interest is Internet access traffic. For Internet access traffic to a modem pool of an ISP, the calling pattern involves a high volume of incoming calls and a long average hold time. If the pattern is consistent with ISP access, there will be no outgoing traffic from a number assigned to an ISP hunt group.

FIG. 3

depicts the high-level process flow of a method for finding telephone numbers of ISPs and estimating the number of lines that the competing carrier provides to the ISPs.

Again, the first step (S

31

) of the ISP finder process involves compiling data from the specific monitored messages to form detailed records (CDRs) of calls interconnected across the interface between the two carriers' networks. For an ISP finder, these CDRs at least relate to all calls attempted or completed for termination in the network of the competing carrier. The detailed call records are processed to create relevant summary information characterizing the call traffic through the selected portion of the network (S

32

). For example, at this point, the summary data will indicate the number of calls to each destination number as well as the time and duration for each call into the other carrier's network.

The ISP finder routine (

FIG. 3

) then executes a series of steps to filter the information based on call statistics relative to the users' telephone numbers, to develop a list of candidate numbers. In the ISP finder application, the filter operations collect telephone numbers for which the statistics indicate a high volume of incoming calls, long hold times and no outgoing traffic. Thus, the step S

33

serves to identify destination telephone numbers within the CLEC network to which the LEC network processed a high-volume of calls. This operation may identify all numbers associated with a volume of incoming calls meeting or exceeding a threshold. Alternatively, the process may select some arbitrary number of destinations having the highest incoming call volumes, e.g. the top fifteen. Data relating to destination numbers having a relatively low volume of incoming calls is discarded.

From the numbers identified in step S

33

, the process now identifies those numbers for which the calls exhibited a long average hold time per call (S

34

). Average hold time associated with one of the numbers is calculated by dividing the total connect time (CCS or MOU) for calls to or from the telephone number by the total number of calls for that number. The total calls may be the count of all calls initiated or the count of all calls completed for that destination number. Again, Data relating to telephone numbers not satisfying the criteria, i.e. having relatively low average hold times, is discarded.

At this point, the first two filter steps (S

33

, S

34

) have culled the data down to identify a list of those numbers satisfying the criteria for high volume and long average hold times. Depending on the level of accuracy desired, this list of candidate numbers may actually be sufficient. However, the procedure may go through another filter operation to determine whether or not there were any outgoing calls associated with each number (S

35

). This operation deletes numbers for which there were outgoing calls from associated stations in some way processed through the LEC network. The result at this point (S

36

) is a small subset listing of the destination numbers in the competitor's network found to satisfy all of the filter criteria, i.e. high volume, long average hold time, and no outgoing traffic.

At this point, the list may be compared to a list of known ISP numbers served through the competing carrier's network. From this comparison, the routine would develop a list of new ISP candidate numbers (S

36

), and the new numbers may be used to update the list of known numbers. If further confirmation that any of the numbers are those of ISPs is desired, for example to confirm that new numbers are those of ISPs before updating the list of known numbers, a carrier technician can make telephone calls to the candidate numbers (S

37

). If the technician hears a modem answer tone, then the telephone number points to a data device of the type that might be operated by an ISP. Actual tests of the procedure shown in

FIG. 3

have produced candidate number lists at S

36

that identified ISPs to an accuracy of 95% or better when tested by follow-up calls (S

37

).

To this point, the process of

FIG. 3

identifies the lead telephone numbers of ISPs operating through the competing carrier's network. Again, the CDRs are available for further processing. Here, the CDRs relate to the interconnect traffic to the identified ISP numbers. Based on the connect time identified in the CDRs, it is then possible to estimate the number of lines within each of the ISPs' hunt groups (S

38

). Specifically, the routine of

FIG. 3

estimates the number of lines in each group from the CCS during the peak busy hour associated with each ISP lead number.

The study of competitors in accord with the techniques exemplified by

FIGS. 1

to

3

preferably will provide regular reports at pre-established intervals. These reports provide much needed “bypass actuals,” which can then be used to establish a “current” total base of the competitors' lines. Ultimately all major CLECs, cellular systems, Personal Communication Service (PCS) systems and cable based telephone networks should be periodically studied. As a time series is developed for each “forecasted element”, trends can be determined and used as a basis for forecasting. The ideal frequency of reports is once per month; however, measurement limitations may dictate quarterly, semiannual or even annual measurements of the market.

As shown by the above discussion of

FIGS. 1

to

3

, the processing of the CDR data enables a carrier such as a LEC to accurately quantify another carrier's customer base, distinguish certain types of service and/or customers of the other carrier, and analyze traffic patterns of the other carrier's customers. An accurate profile of a CLEC and its customer base can be derived through the processing and analysis of interconnect CDR's. As an example, with the above-discussed system programs, an incumbent LEC may produce, the following characteristics of a particular CLEC switch: Calling Party Number percentages, Originating and Terminating point code and usage distributions, Percent Data calling originating from the CLEC switch, Percent Data calling terminating to the CLEC switch, usage growth rates, and access line growth rates. These statistics can be used to highlight and detect possible access fraud conditions between the incumbent LEC and CLEC. As well, the acquired knowledge of the CLEC network can be valuable in assessing and reacting to competitive threats.

The traffic analysis utilizes monitoring of management data developed by the carrier (e.g. LEC) from signaling during processing of interconnect traffic across the interface between its own network and the network of the other carrier.

FIG. 4

provides a high-level illustration of the functions involved in preferred embodiments of the traffic studies, used to analyze interconnect traffic between two carriers, in accord with various preferred aspects of the invention.

In reality, the public network that we think of as the telephone network comprises many segments operated by different carriers, including local exchange carriers (LECs) and interexchange carriers (IXCs). For purposes of this discussion,

FIG. 4

illustrates three such segments or sub-networks. One sub-network is a network

3

1

, operated by a LEC. The LEC is the carrier interested in traffic analysis, for purposes of this discussion.

The second sub-network could be that of an IXC or any other carrier, but for purposes of this discussion,

FIG. 4

depicts a second network or segment

3

2

operated by a Competitive Local Exchange Carrier (CLEC). The first two networks

3

1

and

3

2

are interconnected by trunk links (solid line) for carrying the actual traffic and by signaling links (dotted line).

FIG. 4

depicts a third carrier's network

3

3

. The third carrier's network connects to the LEC's network

3

1

through trunk links (solid line) for carrying the actual traffic and through signaling links (dotted line). In a typical example, the third carrier would be a cellular provider or an IXC providing bypass service to large commercial enterprises.

Typically, customers using telephones such as the telephones

1

make calls through the public switching telephone network (PSTN)

3

. The PSTN provides switched connections between calling and called stations, supporting voice-grade communications between the stations. The parties may use the switched voice-grade connections for conversational speech. Today, many parties also use the telephone connections through the PSTN to communicate other information, e.g. data modulated onto carrier waves within the audio bandwidth of the telephone network

3

.

The telephone calls may stay entirely within one carrier's network, for example when a party using PC

7

A

calls the station

1

A

, both of which receive switched telephone service from the LEC network

3

1

. Some calls, however, interconnect between two carriers' networks. For example, a call from the PC

7

A

to the ISP equipment

7

C

would go first through the LEC network

3

1

and then through the CLEC network

3

2

.

Some calls between two carriers' networks actually transit one or more other carriers' networks. In the illustrated example, the third carrier does not have a direct link into the CLEC's network

3

2

, and calls between the networks

3

2

and

3

3

must transit the LEC's network

3

1

. IXCs often have agreements with CLECs to bypass the LEC, and therefore will have direct network connections to the CLEC networks as illustrated by the IXC networks

3

4

. However, a cellular carrier or another CLEC may not have such an arrangement with the CLEC network

3

2

. In such a case, the third carrier's network

3

2

initiates and receives calls through the landline network via the LEC network

3

1

, including calls to and from parties served through the CLEC network

3

2

. Most IXCs

3

4

will have network connections to the LEC network

3

1

and to all CLEC networks

3

2

in a particular region and will provide long distance interconnection as represented by the arrows.

Set-up and tear-down of a call connection traversing two switching offices of the PSTN requires an exchange of various signaling information between the two switching offices. Similarly, set-up and tear-down of a call connection traversing two or more carriers' networks requires an exchange of various signaling information between offices communicating over interface(s) between the networks. Some systems still utilize in-band signaling, within the voice channels on the interconnecting trunks. However, increasingly, the carriers utilize an out-of-band signaling technique commonly referred to as “Common Channel Signaling” or “Common Channel Interoffice Signaling” (CCIS).

In accord with the invention, certain monitoring equipment in one carrier's network, such as the LEC network

3

1

, receives the signaling messages exchanged between that network and either or both of the other carriers' networks

3

2

and

3

3

and accumulates records

5

of the details of the calls. The call detail

5

for each call includes a wide variety of different items of information about the call. For example, the information may include calling and called party numbers, the time of the call, the duration of the call if completed, the type of release if terminated without completion, identification of office(s) serving the call within each network, etc. The monitoring equipment in the LEC network

3

1

accumulates similar call detail records

5

for calls to and from telephones

1

A

,

1

C

as well as calls to and from data devices, such as calls from the personal computer (PC)

7

A

to an ISP

7

C

.

The call details

5

are supplied through a database input procedure

50

, referred to as a “landing zone” process. The landing zone (LZ) process

50

serves to format the data and load the call details into appropriate tables in one or more relational databases

60

. An example of appropriate database software is available from Oracle.

The landing zone process

50

manages the incoming CDR data streams, checking for errors and loading the data into the relational database tables. The LZ

50

buffers incoming records and periodically uploads the records into the tables. The records follow a first in, first out logic at the landing zone. If two types of call detail records are used, e.g. SS7 and AMA, the landing zone

50

may actually comprise two different LZ routines.

The relational database

60

stores the bulk detail data in an accessible form. A Multi-dimension Database system (MDDB) can be used, to enable analysis and presentation of study results. Alternatively, it is possible to use standard queries (i.e., PL/SQL) that run against the stored relational database call detail records tables, to produce files that are in turn packaged into spreadsheet reports to provide the analysis of interconnect traffic of CLECs or other carriers.

However, still further processing is preferred, to allow analysis and output of the results in desired aggregate forms. Data from the relational database

60

is prepared and uploaded in process

70

for input for On-Line Analytical Processing (OLAP)

80

. The preferred embodiment of the on-line analytical processing routine comprises a multi-dimensional database (MDDB) with a presentation layer. The presentation layer may be an independent program or an integral element incorporated in a software package with the multi-dimensional database. The presentation layer provides the user interface, for example in the form of a client-server interface or a web-browser interface. The presentation layer offers the user fast and flexible access to the study data.

The data preparation process

70

summarizes details of calls and categorizes calls into logical groupings. One other function of the data preparation

70

is categorizing calls into “bins” based on the time and duration of the calls.

The data preparation process

70

also may involve modifying each call detail record by application of reference data from other sources, such as profile or service information of one of the parties to the call. In this part of the data preparation operation for studies of interconnect traffic, one specific purpose is to combine information from call detail records with external support system data. For a CLEC traffic study application, this operation might identify the end office switch in the LEC network that serves callers who originated calls to destinations served through the CLEC network. For a study of competitive loss or gain, where local numbers are portable, this process might identify numbers ported from the LEC to the CLEC and the party who previously used each ported number through the LEC network. Preferably, the enhancement of the data with reference information utilizes middleware that takes the form of a relatively universal system, with an interface to other data systems, whether it is for forecasting or for looking at marketing data, demographic data, etc.

The processed call detail information is uploaded to the OLAP

80

. The OLAP process

80

runs one or more applications to analyze the prepared call details and compile data into reports, for output to a user's terminal

9

. The OLAP process provides certain study management tools as well as the user interface. For example, the OLAP system

80

receives the inputs and presents outputs via the user terminal

9

, to set up study models, to set-up specific studies using established models and to present study results. The preferred embodiment of the OLAP software is a multi-dimensional database (MDDB) with an integrated presentation layer.

The MDDB

80

captures and stores high level summary data and displays it through the user terminal

9

in a variety of ways. The MDDB enables the user to overlay multiple dimensions when viewing the data, for example, showing originating traffic from one area code generated during certain hours of the day with an average call holding time greater than a specified threshold. The preferred MDDB offers the manipulation of data in a cube concept, where data can be approached from many different directions, providing different slices or views of the data. The preferred MDDB also uses a “drilling down” feature to slice or roll-up (aggregate) data based on the metrics (Minutes of Use, Average Holding Time, Busy Hour identification, etc.) required. The drill-down feature enables the user to access the raw call detail information, when necessary. As one example of drill-down, having found an ISP

7

C

served through the CLEC network

3

2

, a user might drill-down into the call details to identify originating offices within the LEC network

3

1

for calls to that ISP or even telephone numbers of subscribers calling that ISP. Such a drill-down analysis might enable the LEC engineer to design and deploy new network equipment to relieve congestion caused by such Internet access traffic. The drill-down feature also would enable the LEC to identify its own customers that are accessing the particular ISP served by the CLEC.

The application running on the MDDB may also provide another point at which the user may access external reference data. For example, having found candidate numbers for ISPs, the application may compare the numbers to those of known ISPs, and reduce the list to a list of new ISP numbers within the CLEC's domain.

The MDDB allows export of data, e.g. to copy a particular presentation from the MDDB into a spreadsheet such as into Excel. The user can then do his own analysis in Excel.

At a higher level, the MDDB enables presentation of aggregate traffic pattern data. For example, it is possible to display Internet access traffic as a percentage of all traffic to a particular CLEC, either based on peg count or usage (e.g. MOU or CCS).

Multi-dimensional database software providing these capabilities is available from Gentia Software, Inc. of Wakefield, Mass. under the product name of Gentia DB. The Gentia DB is a fully OLAP-compliant multidimensional database. Similar to Essbase, it is loaded with data derived from various company data sources, and is pre-consolidated. Gentia supports an “unlimited” number of dimensions, as well as multiple hierarchies within a dimension. It is a fully object oriented visual development environment, with a library of predefined objects, and provides an OLAP database with tools for loading, analysis, querying, and reporting.

Gentia runs on multiple platforms and is scalable across a large system. The multi-dimensional database program could run on a server, and the relational database

60

might run on a separate server. Alternatively, two or more of these databases may run within one computer system or server. The server running the multi-dimensional database (MDDB)

80

is accessed by multiple user work stations

9

. Although the system may implement a client-server interface, preferably, the database

80

provides a web suite for a user interface, enabling access using standard browser software in the workstations. The actual server may connect directly to the terminals

9

or communicate therewith through a data network, such as a private LAN or WAN or the Internet.

Logically, the data preparation software

70

runs as a separate (e.g. Oracle) relational database. The MDDB is platform independent and may run in the same server as the relational database or in a separate server. The data preparation software accesses records from each relational database and uploads data to the MDDB. The MDDB processes data from those records to generate the analytical tables, reports and graphs.

The web suite software together with the MDDB software performs all necessary OLAP processing. As part of this function, the software implements a Data Collection and Study Management Tool set, which enables the user to set up and control studies using the traffic track system and run applications to obtain the analytical results. A more detailed description of the MDDB operations and this Tool set appears in commonly assigned copending application Ser. No. 09/188,712 entitled “TRAFFIC TRACK USAGE MEASUREMENT SYSTEM” filed Nov. 10, 1998, and that description is incorporated herein by reference.

The present inventions provide effective monitoring of various systems and carriers' portions of a public telephone network and processing of the data derived from such monitoring, to enable analysis of various patterns of the traffic across the interface between carriers' networks. The monitoring and analysis may utilize automatically generated accounting (AMA) messages. In the preferred embodiments, the monitoring involves capture of interoffice signaling messages relating to interoffice telephone calls interconnected between the two carriers' networks.

In virtually all interconnect traffic, every call made is an interoffice call. For example, one hundred percent of LEC/CLEC calls may be tracked by monitoring the interoffice signaling. Typically, interconnect traffic to the network of a cellular provider or an IXC also is interoffice traffic and may be analyzed by monitoring interoffice signaling. The interoffice signaling theoretically could be in-band signaling, but preferably, involves out-of-band signaling, i.e. some form of common channel signaling. In the preferred embodiments, the interoffice signaling takes the form of a signaling system seven (SS7) compliant common channel interoffice signaling network. The SS7 signaling extends through and between both carriers' networks.

To facilitate understanding of these preferred embodiments of the invention, it may be helpful at this point to review the structure and operation of the telephone network, in somewhat more detail.

Referring to

FIG. 5

there is shown a block diagram of a public switching telephone network and the SS7 network that carries the call control signaling for the switched network. The PSTN comprises networks operated by many carriers. The invention enables one carrier to monitor and analyze interconnect traffic across the interfaces between networks of different carriers, to analyze other carrier's business and thus project impact thereof on the carrier's own business. Persons skilled in the art will recognize that the traffic tracking may apply to any such interconnect traffic. For purposes of discussion of

FIG. 5

, it is assumed that the interconnect traffic crosses the interface between two carriers' networks, specifically between a LEC network

3

1

and a CLEC network

3

2

.

The switched portion of telephone network consists of a series of central office (CO) switches, which are conventionally referred to as signaling points (SPs) in reference to the SS7 network or as service switching points (SSPs) in reference to an intelligent version of the PSTN. Certain of these SPs comprise end offices (EOs) illustrated at

11

,

13

and

15

in the drawing. Other SPs serve as tandem offices, illustrated for example at

17

and

19

in this drawing.

Customers' telephone equipment connects through telephone lines or other links to the end offices. Examples of such equipment include normal telephone stations shown at

1

A

,

1

B

and

1

C

as well as various data devices such as the PC and ISP hardware shown at

7

A

,

7

B

and

7

C

.

Each office serving as a signaling point has a point code comprising a 9-digit code assigned to every node in the signaling network. Messages communicated via the SS7 signaling network utilize the codes to identify source and destination SPs, and the traffic tracking system can use these point codes to identify messages relating to traffic through particular offices.

The end offices

11

and

12

represent end offices in the region of one operating company or LEC, whereas the end office

15

represents one of the end offices in the region of a different operating company, in this case a CLEC. Each operating company or carrier has its own network or “member” ID, which is used as the first three digits of the point codes of the SPs of that carrier's network.

Also, each end office resides within an area assigned NPA digits as an area code. Each exchange is identified by one or more three-digit codes, referred to as NXX digits. Each such code corresponds to the NXX digits of an NXX-XXXX (seven-digit) telephone number or the three digits following the three area code digits (NPA) in a ten-digit telephone number. Origination and destination telephone numbers appear in various SS7 signaling messages and various records that the offices create for billing and the like. As a result, the NPA-NXX digits of those telephone numbers also can serve as identifiers of the serving end offices.

Digital trunk circuits, shown as solid lines, interconnect the switching offices of each network

3

. Typically, within one carrier's network

3

1

end offices, such as end offices

11

and

13

, are directly interconnected by trunk circuits. For overflow traffic and/or for connections to other carrier networks, the offices

11

and

13

also connect via trunk circuits to a tandem office

17

. In the CLEC network

3

2

, the end office

15

connects through a trunk circuit to a tandem

19

or directly to other end offices (not shown). The LEC and CLEC networks

3

1

,

3

2

interconnect through trunk circuits shown for example between the tandems

17

and

19

, although end office interconnections are possible.

The preferred embodiments of the present invention rely on monitoring of interoffice signaling messages. To understand the monitoring functions it may be helpful to review the interoffice signaling functions of the network.

The SS7 type interoffice signaling network comprises a series of Signal Transfer Points (STPs) shown here at

21

,

23

,

25

and

27

and interconnecting data links indicated by dotted lines. Each STP in a network connects to the SP or SSP capable offices in that network via A links. Thus, in the LEC network

3

1

, the end offices

11

,

13

and the tandem

17

connect to the STPs

21

,

23

through A links. Similarly, the end office

15

and the tandem

19

, in the CLEC network

3

2

, connect to the STPs

25

,

27

via A links.

Within the LEC network

3

1

, the STPs

21

and

23

constitute a mated pair of STPs connected to each other via C links. Within the CLEC network

3

2

, the STPs

25

and

27

also constitute a mated pair connected by C links

58

. Each of these mated pairs serves its respective transport area and/or carrier network. Persons skilled in the art will recognize that there may be multiple mated pairs per region or carrier, one pair for each designated transport area. Multiple STPs in a carrier's territory may be arranged in a heirarchy. Also, although the STPs appear within one local carrier's network, the CLEC may actually use STPs provided by some other carrier. For example, some CLECs contract with an IXC, such as AT&T, to provide the STP service for the CLEC's network. The STPs provided by the IXC continue to perform the packet switching functions for interoffice signaling for the IXC's own network.

The STP

21

connects to the STP

25

via a B link, and the STP

21

connects to the STP

27

via a D link. Similarly, the STP

23

connects to the STP

27

through a B link, and the STP

23

connects and to the STP

25

through another D link. As will be understood, the A, B, C and D links are physically identical links. The letter designations for these various links relate to cost in terms of ease of access.

The STPs in any mated pair have the same translations. Thus, the translations in STP

21

are the same as the translations in STP

23

, and the translations in STP

25

are the same as the translations in STP

27

. The translations control the message routing through the STP.

The STPs may connect to transactional database systems, such as Service Control Points, Integrated Service Control Points or the like. Such database systems, for example, provide call control information for a wide range of recently developed enhanced features. Other database systems, such as the Line Identification Database (LIDB) provide information for ancillary purposes, for example, for credit card validation, for enhanced versions of Caller ID, etc. The monitoring in accord with the traffic track invention captures messages going to and from the tandems or end offices. This includes messages exchanged between the offices and the database systems. Although possible, for our purposes, it is not necessary at this time to separately monitor the links to the database systems. Therefore, for simplicity of illustration, these databases have been omitted from FIG.

5

.

The present invention preferably conducts studies of competing carriers based on interconnect traffic between the carrier conducting the study and the other carriers. These interconnect studies are based on capture and processing of the common channel interoffice signaling (CCIS) messages exchanged between offices, during otherwise normal call processing, typically implemented in the signaling system seven (SS7) protocol. For SS7, typical application layer protocols include Transaction Capability Application Part (TCAP); Operations, Maintenance, Application Part (OMAP); and ISDN User Part (ISDN-UP or ISUP). TCAP provides the signaling protocols for exchange of non-circuit related, transaction-based information, typically for accessing databases such as service control points. OMAP specifies protocols for certain specialized messages relating to maintenance and operations. Although the tracking system can capture and analyze TCAP and OMAP messages, for purposes of the presently preferred embodiments, the most relevant part is the ISDN-UP, sometimes referred to as “ISUP”.

ISDN-UP specifies the procedures and message protocols for setting up and tearing down trunk connections for calls utilizing common channel interoffice signaling (CCIS). ISDN-UP messages, for example, include an Initial Address Message (IAM), an Address Complete Message (ACM) an Answer Message (ANM), a Release Message (REL), and a Release Complete Message (RLC).

The lower three layers of the SS7 protocol, the network layer, the signaling link layer and the data link layer, form the Message Transfer Part (MTP) of SS7, for the TCAP, OMAP and ISDN-UP protocols. The MTP is common to messages for all applications and provides reliable transfer of signaling messages between network nodes. The MTP relays messages between applications running at different nodes of the network, effectively like a datagram type service.

The SS7 messages comprise digital serial messages sent to an STP for routing.

FIG. 6

provides a graphic illustration of an SS7 message packet. The message is arranged in 8 bit bytes or octets. The message includes octets representing a start flag, a routing label for MTP processing and certain specialized indicators. Examples of such indicators include a Signaling Link Selection code (SLC), a Carrier Identification Code (CIC) and a message type indicator. Octets

15

-N carry the information of the message in the form of fixed, mandatory and optional parameters. The lengths of the mandatory parameters field and the optional parameters field are variable. The message ends with an octet for a cyclic redundancy code for error correction, which typically is followed by the flag at the beginning of the next message.

For purposes of the MTP processing, each SS7 message includes the routing label in octets

2

-

11

. Several of the traffic tracking studies rely on translation and/or analysis of certain addressing information from the SS7 messages, for example to identify originating offices for calls terminated in the CLEC network

3

2

. The addressing information used for the MTP and for the traffic analysis appears in the routing label.

FIG. 7

is a graphic illustration of the routing label of the SS7 message packet. The routing label includes a series of indicators, a service information octet and fields for both destination related addressing and point of origin addressing.

Octet

5

is the service information octet. This byte indicates the type of service information, for example by inclusion of a code for a Message Signaling Unit (MSU).

The origination or ‘calling party’ address for the SS7 packet message itself includes octets

9

,

10

and

11

. These ‘calling party’ address octets carry origination point code (OPC) information, for example member, cluster and network ID information, for the node on the SS7 network sending the message.

The destination or ‘called party’ address for the SS7 packet message itself includes octets

6

,

7

and

8

. These three octets carry destination point code (DPC) information for example member, cluster and network ID information, for the node on the SS7 network targeted to receive the message.

In operation, the translation tables stored in an STP cause the STP to actually route based on the DPC without translating any of the DPC octets into new values. The called party address octets (

6

-

8

), however, may carry other types of called party addressing information and receive different treatment by the STP, such as a global title (GTT) and subsystem number (SSN) information. The STP examines a message signaling MSU type indicator in each message to determine if there is a need for translation, e.g. from GTT to DPC, before routing the message.

In both the DPC and OPC, the member number corresponds to the carrier's network. In the example of

FIG. 5

, the SP capable offices

11

,

13

and

17

of the LEC network

3

1

all would utilize the same unique member number. The SP capable offices

15

and

19

of the CLEC network

3

2

all would utilize a common member number, but that number would be unique and different from the member number used in the LEC network

3

1

. As discussed in more detail later, one feature of the CLEC traffic analysis involves translations of data from the SS7 messages into descriptive textual information, for example, to translate the member number of one or more CLECs into the name(s) of the CLEC(s).

The SS7 network constitutes a highly redundant data network, generally using 56K switched data circuits for the various links to and between the STPs. Because of the redundancy, different signaling messages for a given call may actually transit different routes through the SS7 network.

An SS7 monitoring system may be implemented on any carrier's portion of the PSTN. In the example illustrated in

FIG. 5

, the LEC network

3

1

uses the monitoring and call detail compilation equipment, for the traffic tracking and competitor analysis in accord with the present invention. According to the preferred embodiments, the LEC portion of the public switching telephone network (PSTN) is provided with a traffic monitoring and analyzing system comprising monitors

31

, card cages

33

and one or more site processors or servers

35

, of the type described in detail in the above discussed Pester Patent. One commercial implementation of such an SS7 monitoring system is currently available from Hewlett Packard, under the product name “AcceSS7”.

In the case of a CLEC every call made is an interoffice call, so that one hundred percent of LEC-CLEC calls may be recorded through monitoring of the SS7 signaling. To analyze the traffic to the CLEC network

3

2

, the monitoring takes place on the B and D links between the STP pairs

21

,

23

and

25

,

27

. In each case the monitoring and analysis is completely transparent to the trunk circuits and the customers. However the traffic which is being investigated and monitored is the traffic on the trunks. That is, while the signaling traffic is being monitored it is to the signaling traffic itself that is a matter of concern.

FIG. 5

shows the sets of monitors or interfaces

31

1

,

31

2

to the SS7 links to the STPs

21

,

23

in diagrammatic form, as solid bold lines across respective links. A card cage

33

1

connects the monitors

31

1

to a site processor

35

. Similarly, a card cage

33

2

connects the monitors

31

2

to the same or another site processor

35

. The monitors

31

may be conductively or non-conductively coupled to the links to serve as passive interfaces. Alternatively, the monitors

31

may comprise active traps. The card cages

33

connect the monitors

31

to the site processor

35

for accumulation, storage and processing of the raw SS7 messages.

It is intended that multiple monitoring systems of this type serving different purposes may advantageously exist in the PSTN, for example for operations monitoring and/or fraud detection, in addition to the system illustrated for traffic tracking and competitor analysis. For simplicity and clarity, however, only a single system is here illustrated. In an actual implementation the system performing the monitoring for competitor analysis also performs monitoring for other purposes, for example to track interconnect traffic for reciprocal compensation calculations.

The SS7 signaling in a completed call typically includes an Initial Address Message (IAM), an Answer Complete Message (ACM), an Answer Message (ANM), a Release Message (REL) and a Release Complete Message (RLC). Since the common channel signaling system is intentionally redundant, the messages in a related set may be routed over different links.

Consider first a simple example of a call within the LEC network

3

1

. On a call from PC

7

A

to ISP equipment

7

B

, the IAM may go through STP

21

, whereas the ACM and ANM may just happen to go through the STP

23

. The REL and RCL messages also may use different links and/or different STPs. It is therefore necessary to monitor an appropriate set of links and to reassemble the signaling pertaining to a desired transaction or signaling message set such as for a single call, to provide one call detail record or CDR. This is accomplished in the site processor

35

in a known manner as described in the Pester or Brockman et al. Patents.

It should be noted that the PSTN conducts signaling on all interoffice calls, and the monitoring system can trap messages and compile CDRs for all interoffice calls. In particular, the system provides CDRs for both calls completed to a destination station and calls that terminate without completion. For example, the system accumulates CDRs for calls that are blocked because the called line is busy, because there are no network resources available to the terminating end office (network busy), etc.

With the reassembled message sets, the site processor

35

has the data to show the called and calling stations

7

A

,

7

B

, the start time and elapsed time of the call if completed, the originating office, the terminating office, the cause of release if a call is completed and if a call is not completed, and various other detailed data. By monitoring the SS7 signaling for all of the calls originating in, terminating in or passing through a designated switch, such as the tandem switch

17

, it is possible to analyze the traffic to and from the CLEC. In accord with certain preferred features of the invention, this analysis enables the LEC to identify telephone numbers of customers served by the CLEC and to analyze particularly significant patterns of the CLEC's traffic.

For example, based on a pattern of calls through the tandem

17

to a certain number, it is possible to identify the lead hunt group number of an ISP

7

C, even though that ISP is served through the CLEC switch

15

. Knowing that number, it is possible to gather all of the desired information about calls going to the ISP

7

C via an interswitch path, including the numbers of calling customers and the number of calls or minutes of use of such calls by each customer. Conversely, knowing the number of ISP

7

B

, it is possible to collect numbers of callers to that ISP, including numbers of callers receiving service from the CLEC network

3

2

. From the usage data associated with the lead hunt group number, it is possible to estimate the number of lines that the CLEC provides to the ISP in association with that number.

From this data, the LEC can determine the number of ISP hunt groups provided by the CLEC and can estimate the number of lines in each ISP group. This provides an accurate representation of the size of customer base and the amount of services provided, to enable the LEC to make various related revenue projections. The data also indicates the number of interconnect calls to the ISPs and the connect time for such calls, which may allow the LEC to estimate the total traffic to the ISPs based on knowledge of the CLEC's other customers derived from the study.

The assemblage of the raw call detail data desired for a particular purpose occurs at the site processor level. One or more site processors

35

accumulate the CDRs for the traffic monitoring application of the present invention. Periodically, each site processor

35

transmits the latest set of CDRs over a private wide area network (WAN)

37

, operated by the LEC for its internal business purposes. The WAN

37

may carry a variety of LEC network operations data. For purposes of the discussion, the WAN transports the CDRs from the site processor

35

to a server system

39

running a relational database

60

(

FIG. 4

) for the accumulated SS7 data.

The server system

39

comprises one or more computer systems coupled for communication over the WAN

37

. The computer(s) of the server system

39

run software implementing the landing zone process

50

, the relational database

60

, the data preparation operation

70

and the OLAP

80

. One or more computers in the server system

39

also provide communications between the OLAP program

80

and the user terminals

9

, to enable the users to set-up and manage specific studies and to access results.

The CDR compilation and forwarding routine in the site processor

35

executes a special procedure for long duration calls. If a call is in progress at the point in time for the programmed uploading of CDRs to the relational database

60

, say midnight, the site processor

35

creates a “call-in-progress” CDR, indicating the start time and duration of the call to that point. Later, when the call ends, the site processor creates another CDR as if the call started at the point in time (midnight) and lasted for the remaining duration of the call from that time until release.

It will be understood that some calls are completed through a single switch, such as a call from a PC (not shown) associated with the telephone

1

B through the end office switch

13

to ISP

7

B. Such intra-office calls will not generate the above discussed SS7 signaling and thus will not be reflected in the CDRs developed from such signaling. If a particular study requires tracking of such intra-switch calls, for example if a CLEC connects directly to a port of the end office switch, the invention may also utilize data accumulated from certain switch messages normally utilized for billing and other accounting purposes. A more detailed discussion of using automated message accounting (AMA) records as a secondary source of the CDR data appears in commonly assigned copending application Ser. No. 09/188,712 entitled “TRAFFIC TRACK USAGE MEASUREMENT SYSTEM” filed Nov. 10, 1998, and that description is incorporated herein by reference.

The SS7 network constitutes a highly redundant data network, generally using 56K switched data circuits for the various links to and between the STPs. Because of the redundancy, different signaling messages for a given call may actually transit different routes through the SS7 network. The monitoring system is set for a given study to capture all signaling messages regarding traffic of interest for purposes of the particular type of study application. To understand this point it may be helpful to consider a series of exemplary calls, starting with a simple call and working up to the more complex case of a LEC-CLEC interconnect call.

Returning to

FIG. 5

, consider a study of ISP traffic as a first simple example. The intent is to capture all of the SS7 signaling messages relating to each call to an ISP. Now assume that a user places an Internet access call from the PC

7

A

to the ISP equipment

7

B

. The call is an interoffice call, but it is a particularly simple example because it may not involve any tandem switching.

The user at PC

7

A

activates the appropriate software routine to initiate dialing of the main number of a hunt group connected from end office

13

to the ISP equipment

7

B

. The SP end office

11

generates an Initial Address Message (IAM) with a destination point code for the end office

13

and an originating point code of the end office

11

. The IAM includes a variety of information needed for call set-up, including the dialed number. The end office

11

sends the IAM either to STP

21

or to STP

23

. That STP examines the address information and its translations and routes the message offer the next appropriate link, in this case over the A link to the end office

13

.

In response to the IAM message, the end office

13

determines whether or not one of the lines in the hunt group corresponding to the dialed number is available. If at least one of the lines is available (not busy), the end office

13

generates an Address Complete Message (ACM) to indicate that it received the request for a call and that the called line is available. The end office

13

sends the ACM message back by simply reversing the origination and destination point codes and sending the message over an A link to one of the STPs

21

,

23

. The ACM may or may not go over the A link that carried the IAM to the end office

13

, and it may go to the other STP of the pair. Again, the STP receiving the message examines the addresses and uses its translations to forward the message over another link to the appropriate destination, in this case the end office

11

.

The end office

11

sends ringback tone over the line to the modem in the calling PC

7

A

. At about this time, the end office

7

B

applies a ringing signal to the line to the called station

7

B

. If the PC

7

A

provides audio output, the calling party may hear a ringback tone, and the caller and her data equipment await an answer.

The ISP equipment

7

B

detects the ringing signal, and if operative, that equipment establishes an off-hook condition on the line to answer the incoming call. The end office

13

detects this new condition as an answer and interrupts the ringing signal on that line. The end office

13

also sends an Answer Message (ANM) back through the SS7 network to the end office

11

, indicating that the called station

7

B