WO2001031850A1

WO2001031850A1 - A communications traffic control method

Info

Publication number: WO2001031850A1
Application number: PCT/AU2000/001319
Authority: WO
Inventors: Duncan John Gibson; Hans-Albert Trinkle
Original assignee: Telstra New Wave Pty Ltd
Priority date: 1999-10-27
Filing date: 2000-10-27
Publication date: 2001-05-03
Also published as: AU1117301A; AUPQ368499A0

Abstract

A communications traffic control method, including receiving data on connection requests made on a network, maintaining n counters, n being an integer, and for at least one of the connection requests: (a) allocating the connection request to a respective one of the counters, c, based on a characteristic of the connection request; (b) incrementing the counter c; (c) determining connection requests having the characteristic to be significant when the counter c exceeds a threshold level; (d) decrementing counter x of the counters, x being an integer between 1 and n; and (e) incrementing x mod n.

Description

A COMMUNICATIONS TRAFFIC CONTROL METHOD

The present invention relates to a communications traffic control method, and in particular a method of controlling focused overload in a communications network.

Focused overload occurs in telecommunications networks typically when a number of calls are made to a destination at levels which exceed the capacity of the network to complete the calls. Focused overload also occurs in computer networks, such as the Internet, when a high number of connection requests are made to a location in the network which cannot be satisfied by the network's capacity. Various methods have been adopted to detect when focused overload occurs and then apply restrictions to the network to protect the network and at least allow a level of calls or connections to be satisfied, particularly those of innocent third parties. One method involves processing call traffic records for all of the calls which have failed. Counters are maintained to monitor the level of failed calls to each location. If a counter exceeds a threshold level, then a restriction is imposed on the network to control the level of calls which can be made to that location, so as not to affect calls made to other locations. Timers are maintained to decrement the counters at a fixed rate. This method however suffers the disadvantage that it only takes into account the failed calls and by decrementing the counters at a fixed rate does not take into account the rate at which calls are being made. It may also not be prudent to impose restrictions when a counter threshold has exceeded. It is desired to provide a method and system which alleviates the above disadvantages or at least provides a useful alternative.

In accordance with the present invention there is provided a communications traffic control method, including receiving data on connection requests made on a network, maintaining n counters, n being an integer, and for at least one of said connection requests:

(a) allocating the connection request to a respective one of said counters, c, based on a characteristic of the connection request;

(b) incrementing said counter c; (c) determining connection requests having said characteristic to be significant when said counter c exceeds a threshold level; (d) decrementing counter x of said counters, x being an integer between 1 and n; and

(e) incrementing x mod n.

Preferably the method includes determining connection requests having a characteristic corresponding to said counter x to be not significant when counter x is decremented to an abatement level.

Preferably said counters have a maximum level and said method proceeds from step (a) to step (d) when counter c has said maximum level.

Preferably when all of said counters have been allocated to a connection request characteristic and at least one of said connection requests cannot be allocated to one of said counters, steps (a) to (c) are omitted. Alternatively, counter x may be decremented a plurality of times in step (d).

The present invention also provides a communications traffic control system, including means for receiving data on connection requests made on a network, means for maintaining n counters, n being an integer, and means for executing the following steps for at least one of said communication requests:

(b) incrementing said counter c;

(c) determining connection requests having said characteristic to be significant when said counter c exceeds a threshold level;

(d) decrementing counter x of said counters, x being an integer between 1 and n; and

(e) incrementing x mod n.

The present invention also provides a computer program or software for executing the communications traffic control method. Preferably the system further includes means for generating a display of a traffic history based on said data and indicating said connection requests determined to be significant. Preferably the system further includes means for analysing said data and said connection requests determined to be significant to determine whether to impose traffic restrictions on said network.

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of a preferred embodiment of a traffic control system;

Figure 2 is a flow diagram of a number detection procedure executed by the control system;

Figure 3 is a schematic diagram of counters maintained by the system;

Figure 4 is a flow diagram of an alternative number detection procedure executed by the system; and

Figure 5 is a block diagram of an Internet protocol telephony architecture controllable by the system.

A traffic control system 2, as shown in Figure 1, is used to analyse the traffic records of a communication network 4, the records being passed to the system 2 as a data stream 6. The communications network 4 may be a computer network, such as the Internet or a LAN, or a telecommunications network, such as the PSTN, or a combination of both.

The traffic records contain data on connection request instances and may be obtained from various parts of the network. For example, connection requests on particular links may be monitored or on specific pieces of equipment, such as a switch or a router. In a telecommunications network, the input will include a record for every call, detailing the outcome of the call (busy, connected, failed, etc.) and other characteristic data for the call, such as originating number, destination number, circuit identification codes, etc. The traffic data also includes time stamps for every connection request, if the data is not received in real time. For telecommunications call records, the records may be received in real time from a telecommunications signalling monitoring system. For example, a system to monitor CCS7 data in a telecommunications network can provide a real time data stream, which may or may not include time stamps, for the control system 2.

The control system 2 includes a traffic history system 8, a destination detection system 10 and an analysis system 12 which each receive the traffic data on the data stream 6. The detection system 10 processes the received traffic records to detect the connection requests which may relate to a focused overload. This is normally detected by referring to the destinations associated with the request, i.e. by examining the called numbers for telephone calls. A focused overload generally occurs when a destination receives a disproportionately large amount of traffic, such as during a radio or telephone competition where callers are asked to dial a particular number. It can also occur in the Internet when a particular URL is advertised in association with an event occurring at a particular time. The system 10 executes a destination detection procedure described below to determine and mark destinations as being significant. The significant destinations are those which may relate to a focused overload, and data on these destinations is passed to the traffic history system 8 and the analysis system 12.

The control system 2 is described below, for the purposes of simplicity, primarily with reference to processing call records of telephone calls made on a telecommunications network, with the detection system 10 using detection procedures to detect called numbers which may relate to a focused overload. As discussed different traffic records may be processed and other characteristics of the connection requests of the data stream 6 may determine whether that characteristic is significant. For example, the characteristic may be connection requests originating from a particular network switch on a particular circuit.

The analysis system 12 processes the call records for the significant destinations to determine whether any controls are to be placed on network equipment handling connection requests to the destinations. The analysis system 12 recommends controls, with appropriate parameter values, if necessary, which should be applied in the network 4. The controls ensure that a focused overload situation does not occur which prevents calls or connection requests to other destinations being satisfied. The controls reduce the impact of other customers on the network 4 not making connection requests to a significant destination and ensure network equipment is protected, without waste.

The traffic history system 8 receives and processes the traffic records on the data stream 8 to maintain a history of connection request data, such as call rates, call outcomes, etc. for the stream, together with details concerning any significant destinations detected by the detection system 10.

The control system 2 also includes a display system 14 which generates appropriate displays for operators based on data generated and maintained by the traffic history and analysis systems, 8 and 12. The display system 14 includes a Java applet which receives and processes data from the traffic history system 8 to generate a display of the traffic records, the total traffic, and the detected significant destinations. The system 14 also includes another Java applet which receives, processes and displays a view of the control parameters recommended by the analysis system 12 for the significant destinations. The applets can be viewed by a standard web browser accessing the display system 14.

The control system 2 can be implemented on standard computer hardware having software stored thereon to execute the procedures described herein. Alternatively, dedicated hardware, such as ASICs, can be built to execute all or part of the steps of the procedures. The control system may comprise one computer system, such as a PC or workstation, or a number of distributed computer systems which communicate with one another, as will be well understood by those skilled in the art. A single computer is preferred, which is connected to the network 4.

The destination detection system 10 executes a number detection procedure 20, as shown in Figure 2, to determine destinations which are likely to be causing a focused overload. In particular, call numbers which are generating a large increase in traffic are identified by the procedure 20. The procedure 20 operates on n counters, or "leaky buckets" as shown in Figure 3, which are originally reset to have a value of 0. A counter with the value 0 is considered to be an empty or unused counter that is free for allocation, as described below. For the control system 2, n is set to 10. The procedure 20 begins at step 22 when a call record is received and processed from the data stream 6. At step 22 a determination is made as to whether the details for the received call record matches any of the details for the calls being monitored by one of the counters. The details are contained in the call record and define a number of characteristics of the calls, for example the called number, the originating number, and the routes or circuits used, and switches used. A counter can be assigned to count all calls having a predetermined characteristic. In other words, counters are assigned to call characteristics or details. In the example shown in Figure 3, counters are assigned to monitor and count all calls having a specific call or destination number.

If the incoming call record has, for example, a destination number which matches that of one of the counters, CounterC, then initially a check is made at step 24 to determine if CounterC has reached a maximum value, CounterMax. If none of the new call details match any of the details for the existing counters, then a decision is made at step 40 to determine whether an unused counter is available to be assigned to the incoming details. If so, the new call details are allocated to the unused counter, CounterC, at step 42, and operation proceeds to step 24. If CounterC has not reached CounterMax, CounterC is incremented at step 26 and a check made at step 28 to determine whether CounterC has reached a trigger threshold level, Trigger. If the threshold level has been reached then the details monitored by CounterC are declared to be significant at step 30. For instance, the destination number assigned to CounterC is declared to be significant and is reported to the traffic history system 8 and the analysis system 12. After step 30 CounterX is decremented at step 32. Upon initiating the procedure 20 x of CounterX is set to 0 and is incremented for each loop of the procedure at step 38 by setting x = (x+l)mod n. Step 32 therefore allows the counters to "leak" for each iteration of the procedure 20 which is executed for each call record received and processed. This occurs because if the outcome of decision steps 40 and 28 is negative or the outcome of decision step 24 is positive operation also proceeds to step 32. The procedure 20, in managing the leak rate of the counters based on removing a call from one bucket each time a new call arrives, guarantees the detection of a called number which exceeds a certain percentage of the total offered calls. For example, 10 counters will detect a called number which represents greater than 10% of the total calls processed on the data stream 6. This is particularly advantageous as, in addition to the procedure 20 monitoring all calls, rather than just failed calls, the leak rate does not need to be predetermined or configured for a particular traffic stream as it is controlled by the traffic stream itself, and no timer is required to monitor leak rates.

Counters are leaked at step 32 to free the counters for monitoring of other call characteristics, i.e. destination numbers, and to determine at step 34 when the CounterX has reached a lower threshold, an Abatement level. If so, the CounterX characteristics or details are then declared to be not significant, which resets a previous significant status, and this is reported to the traffic history system 8 and the analysis system 12. Operation ultimately proceeds then to step 38, and after step 38 the procedure 20 returns to step 22 to process the next call record.

The detection system 10 may also execute, in the alternative, or in combination, a second detection procedure 50, as shown in Figure 4. The second procedure 50 is the same as the first procedure 20 except that if a counter is not available at step 40 to allocate the incoming call details to, operation returns immediately to step 22 and the CounterX is not decremented or leaked. Step 32 is also adjusted so as to decrement the CounterX twice. The CounterX is therefore decremented at a greater rate, but only when a call record has been allocated to one of the n counters. Using the counters for called number detection and with 10 counters, this means that a destination will only be declared significant at step 30 if it represents greater than 20% of the 10 most significant numbers. Although all call records are processed, a called number is only declared significant based on its share of the traffic relative to other high traffic destination numbers. The second procedure 50 may be more appropriate in monitoring a network with a large background traffic load, such as a PSTN.

The analysis system 12 receives the list of significant destination numbers and analyses the traffic offered to each of these numbers from each originating point, defined by an originating point code (OPC). The system evaluates which OPC and destination number (B number) pairs require controls to be activated and, if so, the severity of the required control. The system 12 includes a call counter module, a control module and an analysis module. The call counter module maintains counters of total, answered and busy calls for each OPC/B number combination and calls the analysis module when new data becomes available. Essentially the call counter generates statistics based on a sequence of per time interval counts of total, answered and busy call attempts for the pairs. The control module encapsulates information about the control capabilities for the network, including available control settings and grade of service throughput. The control module is used by passing it a set of traffic statistics and it returns the best controls for the statistics. The statistics it receives includes the list of call count samples for an OPC/B number as well as an estimate of the current total traffic as determined by the analysis module. The analysis module is an expert system which determines the control action to be taken based on the statistics supplied by the call counter module. The analysis module uses the control module to make control calculations. The analysis module cancels an existing control if there are no busy calls in the analysed data sent, but uses the control module to update control values for a control if the total calling rate for a pair is greater than 2.5 times the answered rate or a control is already currently active for the pair. The controls are set in each switch handling an OPC/B number pair. Implementation of the controls however is of course dependent on the network, the control infrastructure and the switches being used.

As mentioned previously, the control system 2 can be applied to different communication networks to monitor connection requests. In particular, the system can be used in an Internet Protocol (IP) telephony architecture 60, as shown in Figure 5, where incoming calls are directed to and handled by call servers 62 connected to an IP network 68, such as the Internet. Calls on standard telephones 64 are directed to media gateways 66 of the IP network 68 for protocol conversion and delivery to a call server 62. The call server 62 resolves addresses, selects a routing path and sends appropriate signalling instructions to other machines to connect the calls, such as an SS7 gateway 70. The calls can be made from and connected to a variety of terminals using IP based communication. The terminals may be standard telephones 64 or IP telephones 74, for example. Call servers 62 are generally not aware of the outcome of the calls handled. This information however is not required by the detection procedures 20 and 50, and the detection system can be connected to a call server 62, which is central to all call setups, to monitor all call records sent on a data stream 6 to a billing system 72.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings.

Claims

CLAIMS:

1. A communications traffic control method, including receiving data on connection requests made on a network, maintaining n counters, n being an integer, and for at least one of said connection requests:

(b) incrementing said counter c;

(e) incrementing x mod n.

2. A communications traffic control method as claimed in claim 1, including determining connection requests having a characteristic corresponding to said counter x to be not significant when counter x is decremented to an abatement level.

3. A communications traffic control method as claimed in claim 1, including proceeding form step (a) to step (d) when said counter c has a maximum level.

4. A communications traffic control method as claimed in claim 1, including omitting steps (a) to (c) when all of said counters have been allocated to a connection request characteristic and at least one of said connection requests cannot be allocated to one of said counters.

5. A communications traffic control method as claimed in claim 1, including omitting steps (a) to (e) when all of said counters have been allocated to a connection request characteristic and at least one of said connection requests cannot be allocated to one of said counters, and wherein said counter x is decremented a plurality of times in step (d).

6. A communications traffic control method as claimed in claim 1, wherein said characteristic is destination.

7. A communications traffic control method as claimed in claim 1, wherein said characteristic is destination and origination pair.

8. A communications traffic control method as claimed in claim 1, wherein said characteristic is communications link.

9. A communications traffic control method as claimed in claim 1, wherein said characteristic is communications equipment.

10 A communications traffic control method as claimed in claim 1, including analysing said data and said connection requests determined to be significant to determine whether to impose traffic restrictions on said network.

11. A communications traffic control method as claimed in claim 1 , wherein n is 10.

12. Software stored on a computer readable storage medium having code for executing the steps of the control method as claimed in any one of the preceding claims.

13. A communications traffic control system, including means for receiving data on connection requests made on a network, means for maintaining n counters, n being an integer, and means for executing the following steps for at least one of said communication requests:

(b) incrementing said counter c;

(c) determining connection requests having said characteristic to be significant when said counter c exceeds a threshold level; (d) decrementing counter x of said counters, x being an integer between 1 and n; and

(e) incrementing x mod n.

14. A control system as claimed in claim 13, wherein said executing means proceeds from step (a) to step (d) when said counter c has a maximum level.

15. A control system as claimed in claim 13, wherein said executing means omits steps (a) to (c) when all of said counters have been allocated to a connection request characteristic and at least one of said connection requests cannot be allocated to one of said counters.

16. A control system as claimed in claim 13, wherein said executing means omits steps (a) to (e) when all of said counters have been allocated to a connection request characteristic and at least one of said connection requests cannot be allocated to one of said counters, and wherein said counter x is decremented a plurality of times in step (d).

17. A control system as claimed in claim 13, wherein said characteristic is destination.

18. A control system as claimed in claim 13, wherein said characteristic is communications equipment.

19. A control system as claimed in claim 13, wherein said characteristic is destination and origination pair.

20. A control system as claimed in claim 13, wherein said characteristic is communications link.

21. A control system as claimed in claim 13, including means for generating a display of a traffic history based on said data and indicating said connection requests determined to be significant.

22. A control system as claimed in claim 13, including means for analysing said data and said connection requests determined to be significant to determine whether to impose traffic restrictions on said network.

23. A control system as claimed in claim 13, wherein said analysing means determines control values for said network and applies said control values to adjust traffic restrictions on said network.

24. A control system as claimed in claim 13, wherein n is 10.