Abstract:
A dynamic traffic management method and apparatus is provided for intelligent network (IN) systems. This invention provides for dynamic, real-time Traffic Management of the SSP by the SCP in an IN without manual intervention by telecommunications system technicians. The traffic management issues are moved from the switch to an intelligent network node, thereby furthering the spirit of intelligent networks.

Description:
TECHNICAL FIELD 
     This invention relates to traffic management in telephone systems and more particularly to dynamic traffic management in an intelligent network (IN) of a telephone system. 
     BACKGROUND OF THE INVENTION 
     In presently operating systems, as in European Telecommunication Standardization Institute (ETSI)-INAP, or ITU (CS-IR and CS-2) Traffic Management is manually initiated when the service or network management center has detected a congestion situation or any other situation that requires manually initiated controls. In this situation the personnel at the Network Management Center would have to make a decision as to whether the number of failed calls over specific routes exceeded limits, before invoking the appropriate service logic at the SCP to send a Call Gap command and/or an ActivateServiceFiltering (ASF) command to filter calls over specific routes. 
     Alternatively, with the known ETSI-INAP operations, the SCP can make a decision for Automatic Call Congestion through indirect methods such as arming EDP-4R in every IN call and thereafter keeping a counter at the SCP&#39;s end in order to make the decision on the number of failed calls over a period of time before deciding to send a CallGap or ASF. The filtering criteria is done either based on the CalledAddressValue and/or Service Key when the triggering criteria is met, after the call hits any of the TDPs—TDP2, TDP3,TDP4 etc. With ITU CS-IR TDP4 can be armed in a Notification mode, which can then be used to monitor failed calls over a route. However these methods would unnecessarily increase the traffic over SS7 link between SSP and SCP. 
     Abbreviations used herein: 
     ASF—Activate Service Filtering 
     ASN-1—Abstract Syntax Notation Number One 
     A info—Analyze Information 
     A&#39;d info—Analyzed Information 
     BCSM—Basic Call State Model 
     CS1—Capability Set 1 
     CS1—Capability Set 1 
     CS2—Capability Set 2 
     EDP—Event Detection Point 
     ERBCSM—Event Report BCSM 
     INAP—Intelligent Network Application Protocol 
     IN—Intelligent Network 
     ITU—International Telecommunication Union 
     RRBCSM—Request Report BCSM 
     RSF—Route Select Failure 
     SCP—Service Control Point 
     SS7—Signaling System #7 
     SSP—Service Switching Point 
     TC—Transaction Capabilities 
     TDP—Trigger Detection Point 
     SUMMARY OF THE INVENTION 
     Briefly stated, in accordance with one aspect of the invention, the foregoing problem of the art is overcome and an advance in the art is achieved by providing a method of traffic management using an intelligent network node, such as a Service Control Point, (SCP). This method provides a way by which an SCP can make an intelligent decision by monitoring the traffic over specified routes. 
     In accordance with another aspect of the invention, the aforementioned problems are overcome and an advance in the art is achieved by providing a method and apparatus for managing call traffic in a system having a service switching point (SSP) connected to a service control point (SCP) comprising the steps of: sending a traffic monitoring initiation request from the SCP to the SSP; monitoring call traffic at the SSP according to the traffic monitoring request; sending a response to the SCP including results of said monitoring; determining from said results if traffic management needs to be applied; and if traffic management needs to be applied, applying traffic management. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a diagram illustrating traffic management using known INAP operations. 
     FIG. 2 is a diagram illustrating traffic management using operations according to the present invention. 
     FIG. 3 is flow diagram of a threshold based traffic management sequence. 
     FIG. 4 is a flow diagram of a time duration traffic management sequence. 
    
    
     DETAILED DESCRIPTION 
     FIG. 1 shows a flow diagram of information communications in an ETSI INAP system  10  between a SSP  12  and a SCP  14  during an INAP call traffic management operation using presently existing techniques. First systems personnel send an InitialDP and/or analyzed information message to SCP  14 . The InitialDP message is an invitation to arm an event detection point, such as EDP-4R, in every IN call and thereafter keep a count at the SCP&#39;s end in order to make the decision on the number of failed calls over a period of time. SCP  14  responds with a request for a report on the basic call state model, especially requesting reports for data items 4r, 7n and 9br. SCP  14  also requests analyzed information for the next connect operation from SSP  12 . In response, SSP  12  sends an event report on the basic call state model route select failures (ERBCSM-RSF). After sending the ERBCSM-RSF, SSP  12  sends another InitialDP and/or analyzed information message to SCP  14 , which starts another process to obtain a subsequent ERBCSM-RSF. SCP  14  keeps track of the failing routes before sending a new DestinationRoutingAddress (DRA) sending a Call Gap later after gathering more data. As shown, there are many such message sequences between SSP  12  and SCP  14 , thereby heavily loading the SS 7  connections between them. This is the state of the art before the present invention. 
     As shown in FIG. 2, a method  200  that does not have the disadvantage of burdening the SS 7  connection between SSP  12 &#39; and SCP  14 ′. SSP  12 ′ and SCP  14 ′ are very similar to SSP 12  and SCP 14  in FIG. 1, but have software to provide operation according to the present invention. The new method  200  for system  10 ′ has SCP  12 ′ send a non-call related operation MonitorRouteRequest (new) in which the SCP  12 ′ specifies the route/route list to be monitored. This operation will have parameters which can request the SSP  12 ′ to either inform the SCP  14 ′ when a high watermark of failures has been reached at the SSP  12 ′ (shown in FIG. 3) or to inform SCP  14 ′ of the number failed calls over the specified route(s) within a specified interval during a particular time of day (shown in FIG.  4 ). This is done by the SCP  14 ′ requesting the SSP  12 ′ to dynamically arm DP4 (routeSelectFailure) for a particular set of route/routeList and incrementing a counter whenever calls over the specified route hits this particular DP. This is not equivalent to the arming of a TDP-4 statically. The SCP  14 ′ requests the SSP  12 ′ to increment a routeSelectFailed counter whenever a call over a particular route fails. When the monitoring criteria is satisfied the SSP  12 ′ sends a MonitorRouteReport in a TC-Begin with either the number of routeSelectFailures for a particular interval or by filling in the parameter indicating that the high watermark has been reached. The SCP  14 ′ can now decide to send either a CallGap or and ASF with the appropriate filtering criteria. The filtering criteria can now be based on the number of failed calls in the specified duration because of the information gathered in either a single report or a small number of reports. The SCP  14 ′ can have service logic to calculate the number of calls that should go through and the number of calls which need to be gapped/filtered. The overall result is that the SCP  14 ′ has more real time control of traffic problems in a switch as detected at SSP  12 ′. The gapping/filtering of calls are dynamic and can be done without human operator intervention. Alternatively, the SCP  14 ′ also uses this information when sending the Connect/Analyze Information Operation to the SSP  12 ′. Because of the failed route information, the SCP  14 ′ can avoid those DRAs (DestinationRoutingAddress) which would otherwise go over routes that have a high probably of failing due to network congestion. In such a case, an alternative route is sent in the DRA in the Connect/Analyze Information operation. This will ensure that failure rate of IN calls failing due to network congestion is low and that network loads are maintained within reasonable limits, thereby allowing a greater percentage of calls to be completed by system  10 ′. Such a service can also be used for Automatic Call Distribution (ACD) over routes which are liable to face network congestion to complete a higher percentage of the ACD calls during times of network congestion. 
     The MonitorRouteRequest is a Class 1 operation, meaning that both errors and ReturnResults can be sent for the operation. This operation is a non-call related operation, and should not be sent in the context of the call. 
     FIG. 3 shows a threshold based traffic management sequence. The SCP  14 ′ communicates a start threshold monitoring instruction to the SSP  12 ′ in step  302 . In step  304  a timer is started in SCP  14 ′. The SSP  12 ′ begins monitoring of route failures in step  306 . If the SSP  12 ′ determines that the threshold has been reached in step  308 , a report is sent to the SCP  14 ′. A decision is made in step  310  by SCP  14 ′ of whether the number of failures is too great per unit of time. A “YES” decision results in a traffic management instruction being sent in step  312 . A “NO” decision terminates the logical process at END step  320 . 
     FIG. 4 shows a time duration based traffic management sequence. Beginning in step  402 , SCP  14 ′ communicates an instruction to the SSP  12 ′ to start monitoring to a time limit. In step  404  a timer is started in SSP  12 ′. As indicated in step  406  the SSP  12 ′ monitors route failures until the time limit expires and upon time limit expiration, in step  408 , sends a report to the SCP  14 ′. A decision is made in step  410  by SCP  14 ′ of whether the number of failures within the time limit is too great. A “YES” decision results in a traffic management instruction being sent in step  412 . A “NO” decision terminates the logical process at END step  420 . 
     The following are technical definitions of the SCP function (SCF) and the SSP function (SSF) operating SSP  12 ′ and SCP  14 ′ to provide the method  200  and error messages also. The technical definitions are specified in ASN-1 (Abstract Syntax Notation #1) defined in CCITT X.208 (1999). 
     
       
         
               
               
             
               
               
               
             
               
               
             
               
               
             
               
               
               
             
               
               
             
               
               
               
               
             
               
               
             
               
               
               
             
               
               
               
             
               
               
               
             
               
               
               
             
               
               
               
             
               
               
             
               
               
             
               
               
             
               
             
               
               
             
               
               
               
             
               
               
               
             
               
               
             
               
               
               
             
           
               
                   
               
             
             
               
                   
                 Service Switching Function 
               
               
                 Service Control Function (SCF) 
                 (SSF) Operation 
               
               
                   
               
             
          
           
               
                   
                 MonitorRouteRequest 
                 ::= OPERATION 
               
             
          
           
               
                   
                 ARGUMENT 
               
             
          
           
               
                   
                 MonitorRouteRequestArg 
               
             
          
           
               
                   
                 RESULT 
                   
               
               
                   
                 ERRORS 
                 { 
               
               
                   
                   
                 MissingParameter, 
               
               
                   
                   
                 SystemFailure, 
               
               
                   
                   
                 TaskRefused, 
               
               
                   
                   
                 UnexpectedComponentSequence, 
               
               
                   
                   
                 UnexpectedParameter 
               
               
                   
                   
                 } 
               
             
          
           
               
                   
                 Operation Timer 
               
             
          
           
               
                   
                 Operation name 
                 Timer 
                 Value range 
               
               
                   
                   
               
               
                   
                 MonitorRouteRequest 
                 T 
                 Short (1 to 10 seconds) 
               
               
                   
                   
                 Mrr 
               
               
                   
                   
               
             
          
           
               
                 Argument Data Type 
                   
               
               
                 MonitorRouteRequestArg 
                 ::= SEQUENCE { 
               
             
          
           
               
                   
                 routeList 
                 [0] RouteList, 
               
               
                   
                 correlationID 
                 [1] CorrelationID, 
               
             
          
           
               
                   
                 monitoringCriteria 
                 [2] MonitoringCriteria, 
               
             
          
           
               
                   
                 monitoringTimeout 
                 [3] MonitoringTimeOut, 
               
             
          
           
               
                   
                 startTime 
                 [4] DateAndTime    OPTIONAL, 
               
               
                   
                 extensions 
                 [5] SEQUENCE SIZE (1.. 
               
               
                   
                   
                 numofExtensions) 
               
             
          
           
               
                   
                 of 
                 ExtensionField OPTIONAL 
               
             
          
           
               
                   
                 ... 
               
               
                   
                 ... 
               
               
                   
                 } 
               
             
          
           
               
                 RouteList 
                 ::= SEQUENCE SIZE (1..NOS) of 
               
               
                   
                 OCTET 
               
             
          
           
               
                   
                 STRING (SIZE(minRouteListLength 
               
               
                   
                 maxRouteListLength)) 
               
             
          
           
               
                 −− Indicates a list of trunk groups or a route index 
               
             
          
           
               
                 MonitoringCriteria 
                 ::= CHOICE { 
               
             
          
           
               
                   
                 threshold 
                 [0] Integer4 
               
             
          
           
               
                   
                 interval 
                 [1] INTEGER (−1..32000) 
               
               
                   
                 } 
               
             
          
           
               
                 MonitoringTimeOut 
                 ::= CHOICE { 
               
             
          
           
               
                   
                 duration 
                 [0] Duration, 
               
               
                   
                 stopTime 
                 [1] DateAndTime 
               
               
                   
                 } 
               
               
                   
                   
               
             
          
         
       
     
     MonitorRouteRequest procedure 
     When receiving this operation, the SSF monitors specified routes for DP4 hits (RouteSelectFailure). The SSF transfers the results of the operation either when a certain threshold is reached (Monitoring Criteria) or when the stop time is reached. 
     Parameters: 
     1. RouteList: This parameter is used to specify the outgoing trunk group to monitor. A sequence of routes may also be provided 
     2. CorrelationID: This parameter is used by the SCF to associate the MonitorRouteRequest with the MonitorRouteReport sent by the SSF. 
     3. MonitoringCriteria: This parameter specifies when the monitoring results are to be sent to the SCP. 
     A. threshold—This parameter specifies that the report should be sent whenever the threshold is exceeded. 
     B. interval—This parameter indicates that the monitoring report should be sent at the expiration of the interval timer. 
     4. MonitoringTimeout: This parameter indicates the duration, during which the monitoring should be active. 
     A. duration—If the duration timer expires then the monitoring should be removed. 
     A duration of ‘0’ indicates that monitoring should be removed 
     A duration of ‘−1’ indicates an infinite duration. 
     B. stopTime: When the stop time is met then the route monitoring is removed. 
     5. StartTime: This parameter defines when filtering is started. If “startTime” is not provided or was already met, the SSF starts monitoring immediately. 
     Invoking entity (SCF) 
     Normal Procedure 
     SCF precondition 
     1) Service Logic Program Instance (SLPI) decides to monitor traffic over specific routes. 
     SCF postconditions 
     1) Service Logic Program Instance (SLPI) starts an application timer to monitor the expected end of monitoring routes 
     2) The Service Control Functionality Management Entity (SCME) is in the state “Waiting for SSF MonitoringRouteReport”. 
     Responding entity (SSF) 
     Normal procedure 
     SSF precondition: 
     1. None. 
     SSF postcondition: 
     1. The Service Switching Functionality Management Entity (SSME) Finite State Machine (FSM) is in the state “Non-call Associated Treatment”. 
     Error handling 
     1. If the SSF detects an error with any of the defined error values then this error is reported to the SCF. 
     
       
         
               
               
               
             
               
               
             
               
               
             
               
               
               
             
               
               
               
             
               
               
               
             
               
             
               
               
             
               
               
             
               
               
             
               
               
               
             
               
             
               
               
               
             
               
               
               
             
               
             
               
               
               
             
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 SSF - SCF Operation 
                   
               
               
                   
                 MonitorRouteReport 
                 ::= OPERATION 
               
             
          
           
               
                   
                 ARGUMENT 
               
             
          
           
               
                   
                 MonitorRouteReportArg 
               
             
          
           
               
                   
                 Argument Data Type 
                   
               
               
                   
                 MonitorRouteReportArg 
                 ::= SEQUENCE { 
               
             
          
           
               
                   
                 routeCounters 
                 [0] RouteCountersValue, 
               
             
          
           
               
                   
                 correlationID 
                 [2] CorrelationID 
               
               
                   
                 extensions 
                 [3] SEQUENCE 
               
             
          
           
               
                 SIZE(1..numofExtensions) of 
               
             
          
           
               
                   
                 ExtensionField OPTIONAL, 
               
             
          
           
               
                   
                 ... 
               
               
                   
                 ... 
               
             
          
           
               
                   
                 } 
               
             
          
           
               
                   
                 RouteCountersValue 
                 ::= SEQUENCE SIZE(I..NOS) 
               
             
          
           
               
                 RouteCountersAndValue 
               
             
          
           
               
                   
                 RouteCountersAndValue 
                 ::= SEQUENCE { 
               
             
          
           
               
                   
                 route 
                 [0]OCTET STRING 
               
               
                   
                   
                 size(minRouteListLength.. 
               
             
          
           
               
                 maxRouteListLength), 
               
             
          
           
               
                   
                 counterID 
                 [1] CounterID, 
               
               
                   
                 counterValue 
                 [2] Integer4 
               
             
          
           
               
                   
                 } 
               
               
                   
                   
               
             
          
         
       
     
     MonitorRouteReport Procedure 
     General description 
     This operation is used to report the values of route list counters of a previous MonitorRouteRequest operation. 
     Parameters: 
     1. routeCounters: The parameter contains the count of failed calls over selected routes ,during the monitoring period. It is a list of route counter identifications and the related value. If a threshold was specified for a particular route , then the counter value holds the specified threshold value. 
     2. correlationID: This parameter is used by the SCF to associate the MonitorRouteReport from a previously sent MonitorRouteRequest . 
     Invoking entity (SSF) 
     Normal Procedure 
     SSF precondition 
     1) Monitoring of routes is currently running and the interval timer has expired ;or 
     2) Monitoring of routes is running and the threshold value has been reached ;or 
     3) Monitoring has finished (duration time expired or stop time met) ;or 
     4) The operation MonitorRouteRequest is received and encounters an active route monitoring entity. 
     SSF postconditions 
     1) Monitoring of routes proceeds or is ended depending on the duration time. 
     Error handling: Operation related error handling is not applicable, due to class 4 operation. 
     Responding entity (SCF) 
     Normal procedure 
     SCF precondition: 
     1 ) Monitoring of routes is running. 
     2) The SCME is in the state “Waiting for SSF MonitorRouteRequest”. 
     SCF postcondition: 
     The SCME forwards the received counter values to the SLPI. 
     4. Summary &amp; Conclusion 
     Although this invention has been described with respect to a preferred embodiment, those skilled in the art may devise numerous other arrangements without departing from the scope of the invention as defined in the following claims.