EP0986917A2 - Procedes et systemes pour mesurer le trafic de commutation de maniere dynamique - Google Patents

Procedes et systemes pour mesurer le trafic de commutation de maniere dynamique

Info

Publication number
EP0986917A2
EP0986917A2 EP98925182A EP98925182A EP0986917A2 EP 0986917 A2 EP0986917 A2 EP 0986917A2 EP 98925182 A EP98925182 A EP 98925182A EP 98925182 A EP98925182 A EP 98925182A EP 0986917 A2 EP0986917 A2 EP 0986917A2
Authority
EP
European Patent Office
Prior art keywords
traffic
traffic data
component
switch
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP98925182A
Other languages
German (de)
English (en)
Inventor
Stephen T. Cox
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
AT&T Delaware Intellectual Property Inc
Original Assignee
BellSouth Intellectual Property Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/870,369 external-priority patent/US6011838A/en
Application filed by BellSouth Intellectual Property Corp filed Critical BellSouth Intellectual Property Corp
Publication of EP0986917A2 publication Critical patent/EP0986917A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0062—Provisions for network management
    • H04Q3/0091—Congestion or overload control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13164—Traffic (registration, measurement,...)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13166—Fault prevention
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13175—Graphical user interface [GUI], WWW interface, visual indication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13209—ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13349—Network management

Definitions

  • This invention relates to processes and systems for dynamically and automatically measuring traffic across a communication network in order to ensure efficient allocation of network resources.
  • Network traffic management aims to cost-effectively minimize the number of unsuccessful communication attempts caused by network congestion or failure, while also ensuring that expensive network equipment is not over- or underused.
  • the ultimate goal is to provide a given grade of service with the least amount of equipment. To do this, one must determine the amount of traffic handled by the network, particularly by switches in the network. Traffic data describes the amount and features of the communications (voice, video or data) traffic through the network. It is collected to help operators of communication networks determine how efficiently those networks are operating and, if necessary, to plan network reductions, repairs or upgrades. Traffic data also is helpful to large customers who rent or lease network facilities.
  • Two typical ways to engineer switch capacity include extreme value engineering, which engineers switches to accommodate the maximum traffic, or time consistent busy hour engineering, which engineers switches to accommodate the peak traffic during a period that, on average, is most busy.
  • Extreme value engineering provides maximum quality at high cost; time consistent busy hour engineering provides a chosen level of quality at a lower cost.
  • a particular switch component may be servicing 256 lines but be provided with only 64 time slots by which those lines are serviced. (Line units allow the analog subscriber lines to communicate with the digital network). The time slots are less than the number of lines because more than 64 lines are rarely, if ever, in use at once.
  • networks are engineered to keep blocking below a certain absolute percentage, such as 7% of attempted calls, and within a certain average percentage, such as 1.5% of attempted calls.
  • determining that congestion generated "fast busy" signals for over 2% of communications attempted through a particular switch at selected time periods tells network engineers (a) to expect customer complaints about poor service and (b) that the network may need a repair or an upgrade if the problem persists.
  • Peak usage or busy hour refers to the hour of the day in which traffic across the switch hits a peak. (Although the phrase uses the term “hour,” the peak usage can be determined over any time period).
  • the “average” refers to the fact that the average peak usage hour is selected by averaging the traffic across many days and then determining the hour of the day during which peak usage of the network switch occurs. Generally, the average peak usage hour has been determined once per year by manually analyzing the switch traffic usage. The selected "average peak usage hour” is then used for network traffic engineering for the remainder of the year, with switches engineered to handle the volume and type of traffic that occurs during their average peak usage hour.
  • Statistical analysis of traffic data predicts the amount of blocking expected for a given level of switch usage.
  • Two key measurements impact the amount of blocking: the traffic volume handled by the switch and the volatility of the traffic. Volume is typically measured in centume call seconds or "CCS" handled by a switch during an average busy hour determined according to the methods described above. Those methods effectively lower average usage capacity of all switch components to match the worst-performing component of the switch. Volatility refers to the degree of traffic variance from a calculated average. Volatility typically was dealt with by simply discarding traffic data collected for days that were believed to be unrepresentative. For example, in many systems, traffic data for holidays, Saturdays, Sundays and even Fridays was disgarded or ignored when analyzing switch loads. As volatility and capacity increase so does blocking.
  • a second reason for increasingly non-homogenous assignment is the practice of reusing previously assigned facilities when service to a new customer at an old location was introduced (e.g., when an old customer moves, the connection to the residence remains and sen/ice is simply restored when someone else reoccupies the residence). That significantly reduces labor associated with establishing new service at previously occupied locations, but results in less homogeneous traffic because new customers end up being served in a specific, new switch component.
  • the present invention aims to accurately and dynamically determine the traffic capacity of individual switch components in order to provide improved service and to more effectively utilize network switching resources.
  • the invention includes an automated process and system that dynamically and automatically determines the correct peak hour and average usage at that hour (or other time period) for selected components of network elements like a switch.
  • the method involves the steps of periodically collecting and storing segments of traffic data on each switch component over a selected time period; averaging the traffic data of each switch component for each segment across the selected time period; and selecting the peak usage segment.
  • Methods also are disclosed for filtering aberrant or statistically corrupting traffic data from the collected traffic data. Such methods dynamically determine whether particular traffic data is statistically unsuitable.
  • the methods for determining correct average usage and peak hour may be repeated continuously in order to take account of changes in the network load and factor those changes into selection of the peak segment for a particular component. This, in turn, allows the method of the present invention to determine accurately and dynamically the capacity limit for each switch component.
  • Traffic data describing traffic across the switch component at the selected peak usage segment is collected and analyzed. Depending on the results, the load on the selected component may be adjusted or the network otherwise reconfigured.
  • a system is disclosed that performs these processes automatically.
  • the dynamic and automatic process and system of the present invention quickly recognizes volatile traffic usage changes that take place in the communications network in order to increase the accuracy of traffic analysis. Using this process should increase service results, increase capital dollar savings, and reduce manpower requirements. For instance, more accurate usage data informs traffic engineers to take proactive measures to prevent new conditions from impacting service. Equipment can be deployed in more correct quantities in order to save capitalization costs. Replacing a manual process with an automatic one will reduce the manpower - and related operational costs - required to perform the analysis.
  • selected switch components generate and buffer traffic data.
  • a collector periodically retrieves that traffic data, which describes use of the component over a selected time segment or period, such as 30 minutes.
  • the collector provides the traffic data to a database and processor. Because the collector and processor can monitor numerous (e.g., hundreds of) switches with multiple components, the database is helpful for maintaining the large volume of traffic data needed for selecting each component's average peak segment.
  • the database contains at least enough traffic data to create a journal describing a representative period of usage of the component.
  • the journal should be long enough to minimize the impact of a grouping of higher-than-normal daily average peak usage segments, while short enough to respond to a fundamental change in usage of a particular switch or component.
  • the journal acts like a moving window that analyzes the most recent, adjustable number of daily average peak segments to select the average peak usage segment for the journalling period. If a new day's data is added to the journal, any day earlier than the previous 30 days (or other time frame that comprises the journalling period) can be ignored. Selecting an average peak usage segment from a rolling journalling period prevents a spike in a particular component's busy hour from affecting selection of the average peak usage hour. In any event, collecting a journal full of traffic data ensures sufficient data to allow determination of an average peak usage segment that appropriately reflects average peak traffic across various switches and switch components.
  • the processor averages collected, filtered traffic data on each switch component for each segment across an entire journalling period. This process repeats until successive segments in a single day have been averaged with the corresponding 29 (for a 30 day journal) other segments. This determines the average usage of the component during each time segment. The result is an entire day comprising multiple segments with each showing the average usage. The segment at which peak traffic occurred on the component may then be selected.
  • One selection method involves selecting from the traffic data the peak average use of two consecutive segments; this gives the switch component's busy hour (or other time period) if the segments are 30 minute time periods.
  • Traffic data measurements for the selected peak hour are stored for each day in the database.
  • the traffic data can be automatically filtered to eliminate aberrant data, i.e., data that embodies errors or that should be excluded from traffic usage engineering analysis because it falls outside of statistically acceptable bounds.
  • the processor averages the non-flagged traffic data in order to determine the average usage of a particular component at its busy hour.
  • This selection of a peak segment and determination of average usage during the peak segment may be performed daily upon the segments recorded in the journal, which is updated routinely so as to keep only the segments describing traffic over the most recent selected number of days. Because the process selects the average peak usage segment over a rolling, updated journal, changes in traffic patterns for particular switch components or switches during that time period will be dynamically and automatically detected.
  • the data indicating a new average peak usage segment overcomes data supporting the old average peak usage segment. For example, if particular switch components have been handling traffic from a prison that allows inmates to make calls during the 5:00 p.m. to 6:00 p.m. period, that period likely will be the average peak segment. However, if prison officials permanently change the calling time to 7:00 p.m. to 8:00 p.m., the average peak segment would shift to this later period. Assuming a journalling period of 30 days, the present process would detect the shift within about 15 days. Accordingly, a temporary change of less than 15 days would not change the average peak segment.
  • methods of the present invention may be used to more accurately determine capacity of individual switch components. First, non-representative traffic measurements for a particular component's average peak usage segment are identified and removed from the data from which capacity is determined. Next, the method uses the remaining traffic data to determine an average traffic usage limit for the switch component.
  • the method of the invention selects a first mean value for all traffic data measurements at a selected average peak usage segment for a particular journalling period. Thus, if a component has a 2:30-3:30 p.m. average peak usage segment, the mean of the traffic at this time is determined for the prior 30 day journalling period. Next, a lower bound is established. The present invention selects the lower bound as a percentage of the first mean value. Preferably, 95% of the first mean value is used as the lower bound. This value has been found to exclude traffic measurements from low usage days not representative of normal, predominant traffic patterns. Relevant measurements remain to allow proper engineering of the component.
  • an upper bound is established. This is done by determining a second mean value based upon traffic data for the journal (e.g., prior 30 days) that remains after traffic below the lower bound (e.g., 95% of the first mean) is excluded. The method then determines the standard deviation between the second mean and traffic data remaining above the lower bound. An upper bound can then be established based on the second mean plus 2 standard deviations. All daily peak usage segment measurements exceeding the upper bound are excluded.
  • the present invention more accurately eliminates actual non-representative traffic data, by contrast with prior methods, which simply made gross assumptions about which data was likely to be non-representative.
  • the method of the present invention detects changes in traffic patterns that create non-representative data. For example, while prior methods would not detect a snow day or the like during which traffic was particularly high, the present method detects and excludes such unrepresentative data.
  • a third mean value that represents the average monthly traffic usage for the switch component may be determined.
  • This third mean value is used as the average measurement of actual usage for engineering purposes. This value is compared against calculated usage capacity to determine proximity to service limits. It is also used in calculations of average usage per assigned line on the component, which can be used to estimate the number of individual subscribers that can be supported by the component.
  • the usage measurements remaining after the above exclusion process can be used to compute a measurement of volatility exhibited by the data. This volatility measures is computed by the standard deviation of the usage measurement divided by the mean. The volatility measurement can be used to then compute the average usage capacity of the component.
  • a database stores the average usage for a busy hour as well as the traffic usage limit calculated for the switch components.
  • traffic data may include busy hour usage, call attempts or call blocking.
  • the average usage traffic data may then be compared to the component's threshold capacities in order to manage the load on the component. Components that are at, near or over capacity can have their loads appropriately adjusted.
  • An administration network may be provided that can access the stored traffic data and generate reports in order to determine whether objective service levels are being met by the communications network. For instance, various network managers may connect to a network information warehouse holding the collected traffic data for the selected average peak segments of various switch components. Network managers may then run reports to obtain service level measurements, like determinations of a particular component's (or switch's): percent dial tone delay; percent capacity; percent occupancy; percent blocking or any other measurements desired by network engineering.
  • the process of the present invention may be implemented on a computer platform in communication with a particular or numerous switches.
  • a personal computer may be coupled to selected switch components.
  • a warehouse computer platform may be coupled to a collector that polls multiple components of multiple switches in order to collect traffic data describing traffic handled by those switch components.
  • the warehouse platform may couple to the collector that monitors traffic across switches located within a regional communications network, such as a Local Access and Transport Area ("LATA"), or multiple switches in regional networks.
  • LATA Local Access and Transport Area
  • the warehouse platform stores collected traffic data and processes it as described above in order to select the average peak usage segment for a particular switch component.
  • the present invention accordingly aims to achieve at least one, more or combinations of the following objectives: To accurately calculate the operating capacity of individual switch components in order to assign the correct number of lines to particular components.
  • Figure 1A shows a system according to the present invention for processing traffic data collected from a representative communications network.
  • Figure 1 B shows the components of a switch from which traffic data is collected and processed via the system shown in Figure 1A.
  • Figure 2A shows traffic data collected for various segments over multiple days and averaged.
  • Figure 2B shows a collection of averaged segments of Figure 2A that each reflect the average peak traffic for each segment of an entire day.
  • Figure 2C shows the process of updating a journal to create a moving window whose contents reflect the most recent 30 days worth of averaged traffic data.
  • Figure 3 is a flow chart illustrating the steps for collecting and processing traffic data according to the method of the present invention.
  • Figure 4 shows a traffic engineering system for monitoring the load on switch components during their selected average peak segments, comparing the actual load to thresholds and reconfiguring the network to optimize switch component use.
  • Figure 5 shows traffic data for a particular component and a method for flagging aberrant data.
  • Figure 6 shows a load service curve illustrating the difference in operating point capacity of a particular switch component for a particular constant.
  • Figure 7 is a bar graph comparing (a) operating point capacity determined according to prior processes and only based upon overall switch capacity and (b) operating point capacity determined according to the processes of the present invention and on a per switch component basis.
  • FIG. 1A shows a communications network 10, which in the embodiment shown is a telecommunications network provided with Advanced Intelligent Network (“AIN”) and Signaling System 7 (“SS7”) capabilities.
  • Network 10 illustrates one type of network with which the present invention operates.
  • Network 10 has service switching points ("SSPs") 20, 22 and a signal transfer point ("STP") 26, which also couples to a mobile switching center (“MSC”) 24.
  • SSPs 20, 22 can be any telecommunications switch, such as a 1AESS, 5ESS, DMS-100/200, EWS2, DCO, DMS10 or comparable switches (including packet switches).
  • Service control point (“SCP”) 28 couples to the STP 26 (as well as other STPs not shown in Figure 1A).
  • SCP Service control point
  • any of phones 30, 32 may originate a call through
  • SSP 20 by dialing a terminating number to, for instance, wireless phone 34. Originating SSP 20 launches a query containing the dialed destination digits; the query is switched through the SS7 network 10 via STP 26 to a SCP 28 that comprises routing and customer feature databases. SCP 28 provides a route by which the call from phone 30, 32 can travel to wireless phone 34. One such routing may be from originating SSP 20 through tandem SSP 22, which, in turn, terminates the communication to MSC 24. MSC 24 communicates with wireless phone 34 through well-known base stations located at various cell sites.
  • Collecting Traffic Data from Switch Components Network 10 also includes a traffic data collector 40, traffic data processor 42 and network information warehouse (“NIW”) 44, which has a database 41.
  • Collector 40 can be a TDMS ("Traffic Data Monitoring System"), sold by Lucent Technologies (formerly AT&T) or a DCOS 200, sold by Bell Communications Research (also called "BellCore”), deployed, for instance, on a UNIX 3B2/600 platform.
  • Collector 40 couples to the SSPs 20, 22, which it periodically polls for buffered traffic data.
  • switch manufacturers have standardized SSPs 20, 22 to measure and then buffer traffic data every 30 minutes, although SSPs 20, 22 could be modified to measure traffic data more or less frequently.
  • These unprocessed traffic data measurements include measurements on a component level of total usage, maintenance usage, terminating calls and terminating concentrator calls.
  • Total usage measures usually in hundred call seconds ("CCS"), the time the component is in use during the segment. Total usage includes regular use (e.g., by customers) and maintenance usage, which measures the time the component is unavailable to handle regular customer traffic.
  • Terminating calls refers to the number of calls terminated to the line unit ("LU") (or if a 3-way LU, the number of 3- way calls handled by that component).
  • LU line unit
  • Terminating concentrator calls are the number of failed events occurring because all equipment was in use (e.g., blocked calls).
  • Link data may also be measured, or, if the component is a switch processor, its usage level may similarly be measured. (In other words, traffic data includes measurements of the use of switch processors).
  • Collector 40 provides a traffic data stream to the processor 42 and
  • collector 40 may provide its traffic data stream first to a network data system that supports traffic engineering processor 42 and NIW 44 may then obtain traffic data from the network data system).
  • Collector 40 and processor 42 can be deployed on various separate or single computer platforms.
  • a personal computer or work station platform can host both the processor 42 and NIW 44 in order to collect and process traffic data from selected components of multiple SSPs 20 or 22.
  • processor 42 and NIW 44 can be deployed on a warehouse platform such as an NCR 5100 Unix- based server running the Teradata Relational DBMS and sold by NCR.
  • Database 41 may include traffic data records collected by collector 40 and including: (1) detailed traffic data for each monitored switch component for the most recent 90 days (or longer) and (2) historical summary data in the form of a journal of the average busy hour for each of the most recent 30 days used to determine the rolling 30 day average and historical data showing snapshots of daily summary data for the first of each month for a selected time period (e.g., 3 years).
  • Database 41 also maintains various descriptor and reference files. Additionally, various auxiliary sources 45 of data may couple to NIW 44 and provide various types of information to database 41 in order to assist in traffic engineering functions.
  • switch cross-reference tables to help correlate switch location codes that differ among administrative systems
  • traffic tables Poisson distribution tables used in determining component capacities
  • ODF Office Data File with manual configuration or working line data
  • SCM Switch Capacity Manager who is the traffic engineer and the network planner
  • LSD&F Line Switch Demand and Facility, which is a planning system
  • MR7 Management Report 7 that produces statistical monthly reports counting working quantities of customers using certain switch features
  • LNA Line and Number Administration that assigns lines and carrier systems on switches
  • COSMOS a system that mechanically assigns lines to line units
  • FIG. 1 B shows a detailed view of a particular SSP 20, 22.
  • each will have at least the following components from which the collector 40 obtains traffic data: (1) line units that terminate Copper lines (Analog LUs); (2) line units that terminate integrated digital loop carrier lines (DL LUs); (3) line units that terminate ISDN ("Integrated Services Digital Network") lines (ISDN LUs); (4) 3-way conference call or bridging line units (3-Way LUs); and (5) switch processors that run various switch software processes and which the present invention likewise monitors to determine if the processor is over-burdened and needs an upgrade (Switch Processors).
  • Switch Processors switch Processors
  • FIG. 1 B shows that each of these components interfaces to collector 40, which periodically retrieves buffered traffic data.
  • Different switch vendors may provide operator service or other switch components from which traffic data can be collected if desired.
  • SSPs 20, 22 are upgraded to handle the physical line connections required by those technologies. For example, if ADSL becomes a viable technology option, SSPs 20, 22 will be fitted with components to handle customers having those particular types of lines and traffic data may be collected and analyzed from those ADSL line units in accordance with this invention.
  • traffic data is periodically collected throughout an entire 24 hours (or other time period).
  • a “segment” refers to a single traffic data measurement of a single switch or switch component taken during a selected time period, typically, every 30 minutes.
  • the collector 42 takes enough segments to describe the traffic handled by the particular switch component for a working day ⁇ which can be an entire 24-hour period or a shorter period (e.g., like the 12 or 18 most active hours of the day).
  • FIG 3 is a flow chart that shows the steps involved in collecting and processing traffic data from one or multiple switch components.
  • Step 100 begins the process by having the switch component generate and buffer usage information for 30-minute (or other) time periods through the day.
  • Collector 40 retrieves this buffered data. This may involve collector 40 determining at step 102 from which components of SSP 20, 22 traffic data is to be collected. Alternatively, collector 40 can be configured to collect traffic data from a pre-selected set of switch components. For example, collector 40 may periodically poll SSPs 20, 22 to obtain data from each of the components shown in Fig. 1 B. Filtering and Processing Traffic Data
  • Step 102 averages the last 30 days of collected data in the first time period.
  • Step 104 repeats step 102 for each successive time period across the entire 30 days until all of the traffic data for each time period has been averaged.
  • Figure 2A shows representative sets of segment traffic data collected from a selected switch component over several days and averaged. The present invention may be configured so that the collector 42 collects similar traffic data from each component of each SSP 20, 22 within network 10.
  • Step 104 results in a number of average component usages for each time slot, as shown in Figure 2B.
  • Step 106 selects from the averaged traffic data the 2 highest consecutive 30 minute average measurements (e.g., time 2000). This is the selected peak usage segment or "busy" hour, as step 108 indicates.
  • Step 109 waits for an additional day of measurements and then automatically repeats steps 100 through 108 using the last 30 days of collected data. Thus, a journal of the 30 most current days is continuously maintained, as shown in Figure 2C.
  • step 110 stores the traffic data for that busy hour.
  • traffic data stored by processor 40 in database 41 , may be used to determine usage limitations.
  • Step 112 effectively filters the stored usage data by flagging days with abnormally high or low and non-repetitive usages. That data is excluded from the averaging process. For example, the segments collected over 24 hours may be filtered to remove data describing the highest single instantaneous peak segment for a particular component or switch. Thus, the segment for day 5/8/97, time 2300 shown in Figure 2A would be deleted from the traffic data. Alternatively, improved processes described below and in Figures 4-6 may be used to filter data. All of this filtering removes non-repetitive peaks so that they do not adversely effect determination of an average peak segment for a selected journalling period.
  • Figure 3 shows that step 114 averages the non-flagged busy hour measurements recorded for the last 30 days to determine the component average usage during the busy hour.
  • Step 116 repeats the process for determining a switch component's busy hour average usage by using the latest 30 days of non-flagged busy-hour data.
  • Step 118 uses the average usage of the component in the busy hour to compare with thresholds, like the component's computed usage capacity, that describe the component's capacity. Such comparisons are used for load management.
  • Network Traffic Engineering Figure 4 shows a traffic engineering system 60 for monitoring and adjusting loads upon the components of SSPs 20, 22 within a network 10 and based upon selection of the average peak segment for each component of SSPs 20, 22.
  • traffic engineering system 60 aims to: (1) monitor the load on each component during the average peak segment selected according to this invention; (2) compare the actual load determined from such monitoring with a threshold that is the determined or pre-selected capacity of that component; and (3) alert network engineers to particular components' under- or over-utilization so that the network 10 can be more optimally configured.
  • Processor 42 may couple to database 41 and NIW 44 to perform these functions. Processor 42 generally performs the following steps in order to determine whether particular switch components are under- or over-utilized.
  • the average peak usage segment or average peak busy hour is selected for the component, as described above.
  • Processor 42 ensures that traffic data describing component usage during that time period is collected and stored in database 41.
  • Processor 42 determines the average usage of switch components at that average peak segment in accordance with the methods described above.
  • processor 42 identifies the particular component's theoretical load using Poisson tables and calculations. (Telephone traffic is often assumed to have Poisson arrival and exponential holding times, allowing the theoretical load to be calculated using the cumulative Poisson distribution function). Theoretical load must be adjusted to an operating load that ensures the component does not block an unacceptable percentage of calls.
  • Network Information Warehouse (“NIW”) 44 stores and manages the enormous amount of data needed to determine average peak load and theoretical load of the many components of multiple SSPs 20, 22 within network 10.
  • Percentage capacity of the component may then be determined by the processor 42 comparing the average peak load at the average peak busy hour with the operating load. Capacity is then compared to thresholds within database 41. If capacity is at, near or above the threshold, processor 42 may flag the component as potentially over-loaded. Processor 42 may also flag under-loaded components.
  • Display/Terminal 64 and query server 66 allow network 10 traffic managers to run queries and reports against NIW 44 data. Queries may be launched through an administration network 62, which can be a wide area network providing intranet connections within a carrier's region.
  • a single or multiple display/terminals 64 allow for report submission and viewing, ad hoc queries, and descriptor and reference file maintenance.
  • Query server 66 schedules reports and also allows for report viewing and printing.
  • An additional benefit of the present invention involves the ability dynamically to flag and remove from further analysis traffic data that is not representative of typical traffic handled by a particular switch component. This process removes unrepresentative traffic data while also accounting for the overall traffic volatility that a particular switch component handles.
  • Figure 5 shows a sampling of traffic data representing the CCS handled by a particular Line Unit on SSP 20 during the average peak usage segment on a particular day.
  • the method of the present invention establishes an upper bound 50 and a lower bound 52, within which bounds 50, 52 are representative traffic data and outside of which are non-representative traffic data.
  • Traffic data is collected for a selected journalling period, usually 30 days, but Figure 5 shows data collected over an approximately 5 month period.
  • a first mean value 54 is determined based on all of the traffic data collected for the journalling period.
  • a lower bound 52 is selected that is less than, but based upon, the first mean value 54. For example, a lower bound 52 may be established as 95% of the first mean value 54.
  • Daily traffic data that falls below the first mean value 54 is eliminated from the journal.
  • a second mean value is calculated based upon the remaining, first filtered journal data.
  • the method determines a standard deviation between the filtered journal traffic data and the second mean value 56.
  • An upper bound 50 may then be set based upon the second mean value 56 and data exceeding the upper bound discarded to create a twice-filtered journal. For instance, an upper bound 50 that equals the second mean value 56 plus two standard deviations has been found helpful in eliminating overly-volatile traffic data, while keeping the representative data.
  • analog LUs terminate switched, analog subscribers and transform their signals into digital signals understood by SSP 20 and the rest of the network.
  • Analog LUs service multiple lines, ranging from 256 to 640 lines; however, only 64 time slots are available for the LU. Thus, LUs are said to have line concentration ratios of 4:1 (256/64), 6:1 (384/64), 8:1 (512/64) or 10:1 (640/64).
  • Prior processes do not calculate the capacity of each component (e.g., of each analog LU). Instead, operating capacities were calculated for an entire central office SSP 20, based upon the average busy hour for the entire SSP 20 and gross assumptions about which traffic data to flag as aberrant.
  • the present invention accurately determines actual usage capacity or Operating Point Usage ("OP") of each component of SSP 20 using the following formula:
  • CV coefficient of variation
  • Figure 7 shows a comparison between usage determinations according to prior processes and usage determinations made using the methods of the invention.
  • Prior processes simply determined an overall CV for the entire SSP 20 and then used that to determine the average usage capacity (in CCS) for each component in the SSP 20.
  • the present invention calculates a CV for each component of SSP 20 and then determines each component's actual usage limit.
  • SSP 20 may be a 5ESS switch provided by Lucent Technologies with at least 23 Line Units (LUs).
  • Figure 6 compares the actual usage capacity of each LU that the method of the present invention determines against the usage capacity using prior processes.
  • FIG. 6 illustrates that if prior processes are used, LUs 1-11 and 13-23 will each be over-engineered; in other words, each of LUs 1-11 , 13-23 have capacity to handle more calls.
  • LU 12 has been under- engineered and cannot keep up with the traffic assigned to it. This under- engineering would create quality service problems that would be expensive or impossible to diagnose using prior methods.
  • the present invention may be used with various types of communication networks in addition to network 10. Such persons will also recognize the configuration and method of operation of the particular, illustrative network 10 shown in Figure 1. Similarly, skilled persons will recognize that the methods of the present invention may be applied to other network elements, like STPs or packet switches, for which similar traffic data may be collected. Additionally, the type of traffic data collected from such network elements may include the traffic data discussed herein or other data such as the traffic data described in tables set forth in U.S. Patent Nos. 5,359,649 and 5,333,183, each of which are hereby incorporated in their entirety by this reference.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Monitoring And Testing Of Exchanges (AREA)

Abstract

Procédé et système pour déterminer de façon automatique et dynamique le segment temporel exact pendant lequel un commutateur ou les modules d'un commutateur subissent un trafic de pointe dans un réseau de communication. Le procédé consiste à collecter des données de trafic relatives à l'utilisation d'un commutateur sélectionné ou de modules de commutation sélectionnés. Les données de trafic sont collectées pendant une période de journalisation sélectionnée (p. ex. 30 jours), qui est périodiquement remise à jour avec de nouvelles données de trafic pour établir un journal des 30 derniers jours de collecte de données. Les données de trafic collectées sont filtrées pour éliminer les données aberrantes ou parasites. Un segment d'utilisation de pointe moyen est sélectionné dans les données de trafic restantes après le filtrage pour tous les segments de la période de journalisation. En ajoutant régulièrement de nouvelles données et en éliminant les anciennes données du journal, on obtient une fenêtre mobile qui reflète les modifications récentes intervenant dans les pointes d'utilisation. Une sélection régulière (p. ex. quotidienne) du segment d'utilisation de pointe moyenne permet de détecter rapidement de telles modifications à ce qui autorise une réaction et une adaptation dynamiques aux modifications du segment d'utilisation de pointe moyenne pour des modules de commutation particuliers. Les segments d'utilisation de pointe et les données de trafic correspondantes déterminées et collectées par cette invention permettent d'améliorer la gestion du trafic dans le réseau. L'invention décrit en outre un système pour collecter, traiter et évaluer les données de trafic pour organiser les éléments de réseau de manière à assurer un flux de trafic optimal, ainsi que des procédés complémentaires utilisables par le système pour filtrer de manière dynamique les données aberrantes avec une précision accrue et pour déterminer des limites de trafic moyen pour des modules de commutation particuliers. Ces procédés permettent d'utiliser de manière plus efficace les ressources de commutation coûteuses d'un réseau par une détermination plus précise et une identification plus dynamique de l'utilisation du commutateur au niveau modulaire.
EP98925182A 1997-06-06 1998-06-08 Procedes et systemes pour mesurer le trafic de commutation de maniere dynamique Withdrawn EP0986917A2 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US870369 1992-04-17
US08/870,369 US6011838A (en) 1997-06-06 1997-06-06 Process and system for dynamically measuring switch traffic
US6820697P 1997-12-19 1997-12-19
US68206P 1997-12-19
PCT/US1998/011317 WO1998056190A2 (fr) 1997-06-06 1998-06-08 Procedes et systemes pour mesurer le trafic de commutation de maniere dynamique

Publications (1)

Publication Number Publication Date
EP0986917A2 true EP0986917A2 (fr) 2000-03-22

Family

ID=26748697

Family Applications (1)

Application Number Title Priority Date Filing Date
EP98925182A Withdrawn EP0986917A2 (fr) 1997-06-06 1998-06-08 Procedes et systemes pour mesurer le trafic de commutation de maniere dynamique

Country Status (6)

Country Link
EP (1) EP0986917A2 (fr)
AR (1) AR012245A1 (fr)
AU (1) AU7719398A (fr)
CA (1) CA2291027A1 (fr)
PA (1) PA8452801A1 (fr)
WO (1) WO1998056190A2 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2944113B2 (ja) * 1989-11-01 1999-08-30 日本電気株式会社 バッテリセービングシステム
JP2576369B2 (ja) * 1993-08-02 1997-01-29 日本電気株式会社 移動無線通信方式
US5539815A (en) * 1995-02-24 1996-07-23 At&T Corp. Network call routing controlled by a management node

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9856190A3 *

Also Published As

Publication number Publication date
CA2291027A1 (fr) 1998-12-10
AU7719398A (en) 1998-12-21
PA8452801A1 (es) 2000-05-24
WO1998056190A2 (fr) 1998-12-10
AR012245A1 (es) 2000-09-27
WO1998056190A3 (fr) 1999-03-18

Similar Documents

Publication Publication Date Title
US6449350B1 (en) Processes and systems for dynamically measuring switch traffic
US6011838A (en) Process and system for dynamically measuring switch traffic
US6282267B1 (en) Network planning traffic measurement program
US5359649A (en) Congestion tuning of telecommunications networks
US7263180B2 (en) Telecommunication services reporting system
US6381306B1 (en) System and method for monitoring service quality in a communications network
US6298123B1 (en) Interconnect traffic tracking
US7466672B2 (en) System, tool and method for network monitoring and corresponding network
CA1253241A (fr) Service telephonique pour distributeurs d'appels automatiques
CA2159245C (fr) Systeme et methode pour detecter les fraudes par clonage dans les communications radiotelephoniques/stp
US6411681B1 (en) Traffic track measurements for analysis of network troubles
US6359976B1 (en) System and method for monitoring service quality in a communications network
US6351453B1 (en) Internet service provider (ISP) finder
AU725908B2 (en) Dynamic traffic distribution
US6636486B1 (en) System, method and apparatus for monitoring and analyzing traffic data from manual reporting switches
US7324634B2 (en) Telecommunications systems
WO1998056190A2 (fr) Procedes et systemes pour mesurer le trafic de commutation de maniere dynamique
US7631355B2 (en) System and method for identifying extreme behavior in elements of a network
MXPA99011161A (en) Processes and systems for dynamically measuring switch traffic
WO1998044704A1 (fr) Procede et dispositif permettant de surveiller l'exploitation d'un equipement de telecommunication
CA2273443C (fr) Methode et materiel pour determiner la ligne affectee lors d'un blocage de ligne
US20060210063A1 (en) Method, system, and article for informing a telecommunication customer of a future performance estimate for a telecommunication feature
US7643428B1 (en) Early detection of faulty communications links
JP3317978B2 (ja) 出トランク群分散比設定方式
KR0168778B1 (ko) 분산제어 교환시스템의 가입자 데이타수집 및 처리방법

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20000104

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BELLSOUTH INTELLECTUAL PROPERTY CORPORATION

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20050104