WO2007081934A2 - Methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment - Google Patents

Methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment Download PDF

Info

Publication number
WO2007081934A2
WO2007081934A2 PCT/US2007/000492 US2007000492W WO2007081934A2 WO 2007081934 A2 WO2007081934 A2 WO 2007081934A2 US 2007000492 W US2007000492 W US 2007000492W WO 2007081934 A2 WO2007081934 A2 WO 2007081934A2
Authority
WO
WIPO (PCT)
Prior art keywords
application
message
signaling message
signaling
processing
Prior art date
Application number
PCT/US2007/000492
Other languages
French (fr)
Other versions
WO2007081934A3 (en
Inventor
Gaurang Kalyanpur
Peter J. Marsico
Suchetha D. Raghavan
Robby Darren Benedyk
Lane Liley
Apirux Bantukul
Amrit P. S. Wadhwa
Original Assignee
Tekelec
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
Application filed by Tekelec filed Critical Tekelec
Priority to CN2007800084876A priority Critical patent/CN101401086B/en
Priority to EP07709644.4A priority patent/EP1974282B1/en
Priority to BRPI0706370-9A priority patent/BRPI0706370A2/en
Publication of WO2007081934A2 publication Critical patent/WO2007081934A2/en
Publication of WO2007081934A3 publication Critical patent/WO2007081934A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1043Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1033Signalling gateways
    • H04L65/104Signalling gateways in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0025Provisions for signalling

Definitions

  • the subject matter described herein relates to processing signaling messages. More particularly, the subject matter described herein relates to methods, systems, and computer program products for decentralized processing of signaling message in a multi-application processing environment.
  • Signaling messages are used within communications networks to communicate information related to call setup, call tear down, call timing, billing, messaging and many related functions. Signaling messages are processed by various applications to achieve the desired functions. Examples of signaling message processing include triggerless processing of ISDN user part (ISUP), telephone user part (TUP), transaction capabilities application part (TCAP), mobile application part (MAP) and session initiation protocol (SIP) signaling messages in a multi-application environment. Some of the message types, such as ISUP and SIP messages relating to call setup, may be subjected to triggerless processing by a signaling message routing node. "Triggerless processing,” as used herein, refers to the processing of a received signaling message without requiring an end office trigger to initiate the processing.
  • a signal transfer point may perform triggerless processing of received ISUP IAM messages requiring local number portability (LNP) lookups by performing LNP database lookups for the IAM messages without requiring end office trigger to initiate the lookups.
  • STP signal transfer point
  • LNP local number portability
  • Another example of triggerless processing that may be performed for received signaling messages includes screening. For example, received ISUP messages may be screened based on one or more parameters in each message and either routed to their respective destinations, or blocked, depending on the results of the screening.
  • Signaling messages are routed in communications networks through network elements for processing.
  • Some examples of these network elements include an STP, a signaling system number 7 (SS7) Internet protocol (IP) signaling gateway (SG) (collectively SS7-IP SG), an SS7 gateway, a SIP server, a short message gateway (SMG) 1 a Softswitch (SS), and a media gateway controller (MGC).
  • STP signaling system number 7
  • IP Internet protocol
  • SS7 gateway Internet protocol
  • SMG short message gateway
  • SS Softswitch
  • MCC media gateway controller
  • the signaling message may be routed through and by any of these network elements.
  • Some network elements may include screening functions or modules (hereinafter referred to as screening functions). Screening functions have traditionally been adapted to apply a screening policy to a received signaling message and to route the signaling message after the screening policy has been applied. Screening policies may include a variety of processing tasks for any given signaling message. These processing tasks may include processing by one or more message processing applications.
  • Example message processing applications include triggerless pre-paid service applications, number portability service applications, location portability service applications, usage measurements service applications, billing service applications, advanced / intelligent routing service applications (e.g., time of day routing, etc.), messaging service applications (e.g., short message service, multimedia message service, instant message service, etc.), presence service, ENUM service, and other signaling message-based network service applications.
  • screening policies have been implemented by screening functions that manage all aspects of the processing. These screening functions have acted as a cog in a wheel by placing themselves logically in the middle of several processing applications and sequentially sending signaling messages to applications one at a time for processing (as if sending them along the spokes of the wheel to each application).
  • the message is then sent by the application back to the screening function.
  • the screening function determines, based upon the screening policy, which application should process the message next and sends the message to that application. This repeats until all message processing is completed and the message is received back at the screening function. With the screening policy complete, the screening function may then route the signaling message to the next node in the network.
  • screening functions have traditionally managed all aspects of signaling message processing and routing.
  • the traditional approach burdens the screening function with repeated message processing and routing tasks. This repeated processing burden consumes valuable signaling link bandwidth and requires a substantial amount of time.
  • the SS7 signaling protocol includes various call setup timers that effectively limit the delays that ' can be incurred between network elements during call setup operations.
  • Bandwidth is also consumed on the order of 2N (where N is the number of applications). To clarify, for each application required to implement a given screening policy, two transmissions of the message occur: one- from the screening function to the application; and another from the application back to the screening function.
  • the subject matter described herein comprises methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment.
  • One method includes receiving a signaling message at a screening module, determining, from a screening policy, at least one application to perform triggerless message processing on the signaling message, modifying the signaling message to include application routing information to allow the at least one application to complete signaling message routing, forwarding the signaling message to the at least one application, and, at the at least one application, routing the signaling message using the application routing information.
  • completely signaling message routing it is meant that the screening function inserts sufficient routing information in the message for the applications to forward the signaling message between applications designated to process the message without requiring the message to go back to the screening function, and, if the message passes all of the application processing, for forwarding the message to a destination without going back to the screening function.
  • the subject matter described herein providing decentralized processing of signaling messages in a multi-application processing environment may be implemented using a computer program product comprising computer executable instructions embodied in a computer readable medium.
  • Exemplary computer readable media suitable for implementing the subject matter described herein include disk memory devices, chip memory devices, programmable logic devices, application specific integrated circuits, and downloadable electrical signals.
  • a computer readable medium that implements the subject matter described herein may be distributed across multiple physical devices and/or computing platforms.
  • Figure 1 is block diagram of an exemplary system for decentralized processing of signaling messages in a multi-application processing environment according to an embodiment of the subject matter described herein;
  • Figure 2 is a flow chart illustrating exemplary steps by which decentralized processing of signaling messages in a multi-application processing environment may be performed according to an embodiment of the subject matter described herein;
  • FIG. 3 is a flow chart illustrating exemplary steps by which decentralized processing of signaling messages in a multi-application processing environment may be performed using a call detail record (CDR) and a list of parameters (LOP) according to an embodiment of the subject matter described herein;
  • CDR call detail record
  • LOP list of parameters
  • FIG. 4 is block diagram of an exemplary signaling transfer point (STP) including a screening module to identify application processing sequences for screening of signaling messages at applications according to an embodiment of the subject matter described herein; and
  • STP signaling transfer point
  • Figure 5 is block diagram of an exemplary application for decentralized triggerless routing of a signaling message according to an embodiment of the subject matter described herein.
  • the subject matter described herein distributes the responsibility of message routing to the applications that actually perform the screening.
  • a screening function was responsible for all routing activity (a cog in a wheel)
  • the present subject matter includes methods, systems, and computer program products for decentralized processing of signaling message in a multi-application processing environment. By adapting the screening function and screening applications to process routing information differently, bandwidth and temporal savings may be achieved.
  • FIG. 1 illustrates an exemplary decentralized processing system 100 for decentralized triggerless processing of signaling messages in a multi- application processing environment.
  • an SS7 network environment will be discussed.
  • Many other network environments are capable of implementing a screening function, such as, for example, an Internet protocol (IP) based network. Accordingly, all other such networks are considered within the scope of the present subject matter.
  • exemplary network elements within an SS7 network include, for example, a signal transfer point (STP), an SS7-IP signaling gateway (SG), a short message gateway (SMG), a Softswitch (SS) or media gateway controller (MGC).
  • STP signal transfer point
  • SG SS7-IP signaling gateway
  • SMG short message gateway
  • SS Softswitch
  • MCC media gateway controller
  • Exemplary network elements within an IP network include, for example, a SIP proxy server, an IP multimedia subsystem (IMS) call state control function (CSCF) element, and a SIP messaging server.
  • decentralized processing system 100 includes an STP 102, a signaling message screening function 104, a prepaid application 106, a number portability application 108 and a usage measurements application 110.
  • an SS7 ISUP call setup message 112 may be received at STP 102 and directed to signaling message screening function 104 as ISUP message 114.
  • Call setup message 114 may include signaling message parameters derived from call setup message 112, as will be described below.
  • Screening function 104 may be internal to, co-located with, or external to STP 102.
  • Screening function 104 may have access to any appropriate storage device capable of storing databases, tables, or other data structures used by screening function 104.
  • screening function 104 may receive ISUP message 114 and apply a screening policy or screening rule to the message.
  • signaling message parameters may be included within ISUP message 114 and may be used to identify, evaluate and determine the screening policy or rules to be applied, including the sequence of application processing.
  • signaling message parameters used by screening function 104 may include an origination point code (OPC), a destination point code (DPC), a circuit identification code (CIC), a signaling indicator (Sl), a message type, a called party number (CdPN), a calling party number (CgPN), and a carrier ID.
  • screening function 104 or a gateway screening function within STP 102 may make an initial determination as to whether a message is eligible for processing by one or more applications, such as applications 106, 108, and 110.
  • screening function 104 or a gateway screening function within STP 102 may analyze one or more parameters in a message. For example, if the message is an ISUP message, screening function 104 or a gateway screening function within STP 102 may analyze the redirection number in the ISUP message to determine whether a call associated with the message is being directed to voicemail. If the redirection number indicates a voicemail number, it may not be necessary to perform any application processing of the message. Accordingly, the message may be routed to its destination rather than being screened.
  • screening function 104 may be used to implement, for example, intelligent network (IN) and advance IN (AIN) features on behalf of an end office in the form of a proxy service. Screening rules implemented by screening function 104 may dictate that ISUP messages satisfying certain screening criteria should be processed by one or more message processing applications. Further, screening rules implemented by screening function 104 may specify a desired sequence of processing for the message processing applications.
  • a screening rule implemented by screening function 104 may require that an ISUP IAM message associated with a call to (212) 450- 1023 should be first processed by a pre-paid calling service application, then processed by a number portability application, and then processed by a usage measurements application.
  • An exemplary screening rule, as described, is shown in Table 1 where the asterisk indicates that the rule depicted may apply to any called party within area code "212" and exchange "450.”
  • Screening function 104 may also include a data structure which maps application identifiers to SS7 point code addresses associated with screening applications.
  • An exemplary data structure is shown in Table 2.
  • screening function 104 may identify the appropriate screening rule for the call.
  • screening function 104 may generate or instantiate data structures to assist with processing of ISUP message 114.
  • the first may be a temporary call detail record (CDR) or a stateful CDR-like data structure that may include information extracted from ISUP message 114.
  • This temporary CDR may be used to identify the call or call state, respectively.
  • a temporary CDR may include OPC 1 DPC and CIC information, which identifies the call associated with ISUP call setup message 112 and ISUP message 114, as illustrated in Table 3.
  • the temporary CDR may be used by screening function 104 to identify and correlate subsequent ISUP messages (e.g., subsequent address message, address complete, answer, release complete, etc.) that are associated with the same call.
  • the temporary CDR may also include information which identifies applications to which previous messages related to the same call were sent for processing.
  • screening function 104 may then create ISUP message 116 by modifying ISUP message 114 to include application routing information. This application routing information may identify both the applications that are to process the message and the desired sequence of processing.
  • One approach to including routing information within ISUP message 116 may be to create a routing data structure, described herein as a List Of Pointcodes (LOP).
  • LOP List Of Pointcodes
  • this LOP may be included within ISUP message 116 as a routing parameter. There are many other possible ways to include routing information within ISUP message 116 and all are considered within the scope of this subject matter described herein. For simplicity, only the LOP will be discussed in detail.
  • An LOP structure may include any of the following fields: an Application Point Code field, an Application ID field, a Last Application field, and a Dirty Bit field.
  • An exemplary LOP for use with ISUP message 116 is shown in Table 4.
  • the Application Point Code field may include point codes for applications that are to process ISUP message 116.
  • the Application ID field may include a character string or numeric representation of an application identifier.
  • the Last Application field may include a binary indicator that may be set for the application that is to process ISUP message 116 last.
  • the Dirty Bit field may include a binary indicator that may be set by each application sequentially as each processes ISUP message 116. It should be noted that the original DPC of ISUP call setup message 112 has been included in this exemplary LOP as the last application ID. Placement of the original DPC as the last application ID allows preservation of the original DPC within the ISUP message and facilitates routing by the last application to the final destination. This process will be discussed in more detail below.
  • ISUP message 116 may follow the order in which applications are identified within the LOP. As discussed above, this routing sequence specified within the exemplary LOP should result in routing first to prepaid application 106, then to number portability application 108, and finally to usage measurements application 110.
  • applications may be identified within the LOP with both a point code and an application ID. Situations may arise wherein multiple applications may reside at the same point code. In situations such as these, the Application ID may be used by the network element to identify the intended applications at that point code address, and the order within the LOP may still be used to indicate the processing sequence for those applications at the same point code address. Further, in reference to a data structure that may be used to implement the exemplary LOP of Table 4, the application ID may be a binary value, a hexadecimal value, a character string, or any other encoding format.
  • the SS7 point code addresses may be a 24-bit American National Standards Institute (ANSI) format, a 14-bit International Telecommunication Union (ITU) format, or any other appropriate format for point code addresses.
  • ANSI American National Standards Institute
  • ITU International Telecommunication Union
  • the last application identified to process the ISUP message which in the present embodiment is usage measurements application 110, has its Last App bit set to a value of 1.
  • the original DPC parameter value contained in ISUP message 116 may be included as the last entry in the LOP. Details of the use of these fields for processing the ISUP message will be discussed in more detail below.
  • screening function 104 may create ISUP message 116 by inserting the LOP parameter in ISUP message 114.
  • the LOP may be placed in any location that is appropriate for a given protocol.
  • Screening function 104 may then set the DPC field of the message transfer part (MTP) routing label of ISUP message 116 to the DPC of prepaid application 106, which in this example is the first application identified to process ISUP message 116.
  • Screening function 104 may then forward ISUP message 116 to prepaid application 106 by way of STP 102.
  • STP 102 may forward ISUP message 116 to prepaid application 106 as ISUP message 118.
  • MTP message transfer part
  • ISUP message 118 may be received by prepaid application 106 and processing of the prepaid application task may begin. As part of the processing, prepaid application 106 may perform several operations. It may change the dirty bit to "1 ,” thereby representing to subsequent applications that prepaid application 106 has processed the ISUP message.
  • the application may process a message more than once, for example, initially and then again after forwarding the message to another application or applications for other processing, it may keep a copy of the list of point codes to allow it to further operate on the message at a future time. Discussion of this stateful operation will be limited herein for purposes of simplicity. It should be sufficient to note that stateful processing of messages may be achieved by maintenance . of processing sequences within an application so that subsequent operations may be performed by an application after processing is completed by another application or applications.
  • an application may analyze all point code entries in the LOP of a received message to determine whether the next application resides at the same point code. If the next application is present at the same point code, the application ID field may be used to indicate the order of processing. Again, for simplicity, the present embodiment will be described with only one application at each point code.
  • prepaid application 106 may complete its operations on ISUP message 118. It may then analyze the LOP to determine whether it is the last application to process the ISUP message by inspecting the last application bit. Determining that it is not the last application, prepaid application 106 may then look up the first point code in the LOP parameter whose dirty bit is set to a "0.” Prepaid application 106 may then insert that point code as the DPC of the MTP routing label and may forward ISUP message 120 to the next application, which, in this exemplary embodiment, is number portability application 108.
  • number portability processing may be performed, the dirty bit may be set, the LOP parameter may be analyzed to locate the next point code, and the next point code may be inserted in the DPC of the MTP routing label.
  • Number portability application 108 may then forward ISUP message 122 to usage measurements application 110 with the DPC of usage measurements application 110 as the DPC of the MTP routing label.
  • Usage measurements application 110 may collect one or more measurements for ISUP message 122 and examine the LOP parameter to locate the next application. In this example, usage measurements application 110 may recognize that it is the last application by inspection of the last application field in the LOP. It may also recognize that all other application dirty bits are set. Usage measurements application 110 may then replace the DPC of the MTP routing label with the original DPC included as the last entry of the LOP. Usage measurements application 110 may then forward ISUP message 124 to STP 102 with all application processing completed.
  • STP 102 may forward ISUP message 126 to the final destination indicated by the original DPC.
  • screening function 104 is only required to process the original message one time.
  • the 2N routing bandwidth requirements for traditional message screening architectures may be reduced to as little as 1 N, again where N is the number of applications to process a given message.
  • Latency may also be reduced as a function of at least two variables: processing time and transmission time.
  • the reduction in processing time represents a savings over the processing time previously associated with traditional message screening where the screening function processed each message after every application processing event.
  • the reduction in transmission time represents a savings over the transmission time previously associated with the multiple message returns to the screening function.
  • TCAP transaction capabilities application part
  • TUP telephone user part
  • the present subject matter may include processing IP telephony signaling messages, such as SIP signaling messages.
  • a SIP INVITE message may be intercepted at a network routing node, such as a SIP - SS7 Gateway or a SIP server, and directed to a screening function, in a manner similar to that described above with respect to an SS7 ISUP implementation.
  • the screening function may include screening policies or screening rules associated with SIP signaling and SIP users.
  • An exemplary SIP screening rule is illustrated in Table 5.
  • Screening rules may indicate that SIP messages satisfying certain screening criteria should be processed by one or more message processing applications.
  • the screening function may also include a data structure, which maps application identifiers to SIP or IP addresses associated with the applications, such as those illustrated in Table 6.
  • Table 6 Exemplary Application ID/Address Information
  • a SIP screening function may be adapted, for example, to create a temporary CDR or a stateful CDR-like data structure, similar to that discussed above, that includes information extracted from the SIP INVITE message, and which may identify the call or call state for the message, respectively.
  • a temporary CDR may include Call-ID information which may identify a call, as illustrated in Table 7. This temporary CDR may be used by the screening function to identify and correlate subsequent SIP messages that are associated with the same call.
  • the temporary CDR may also contain information which identifies to which applications previous messages related to the same call were sent for processing.
  • the screening function may modify the SIP INVITE message to include information that identifies both the message processing applications to process the message and the sequence in which these applications should route the message. This may, for example, be accomplished using SIP ROUTE and VIA parameters in the header of the SIP INVITE message.
  • a SIP ROUTE header parameter may be used to identify the address of a first message processing application to which the message should be routed. Multiple ROUTE header parameters may be used with each identifying the address of a message processing application to sequentially process the message.
  • the ROUTE parameter(s) may be included in the INVITE message, and the INVITE message may then be routed from the screening function to the first message processing application. Message processing may occur at the first application, as discussed above, and the INVITE message may then be routed by each application to the next for subsequent processing until all applications represented in the sequence of ROUTE parameters have processed the message.
  • a message processing application may insert it's address in a VIA parameter of the INVITE message before routing it on to the next application. In this manner, the message processing application may receive all subsequent response messages associated with the INVITE. This may be accomplished based upon the SIP principle that response message return through addresses specified in the VIA parameter(s) of the INVITE message. Multiple VIA parameters may be included in the SIP INVITE header to allow multiple applications to receive response messages.
  • FIG. 2 illustrates an exemplary decentralized process 200 for processing signaling messages in a multi-application processing environment.
  • decentralized process 200 may receive a signaling message at a screening module.
  • Decentralized process 200 may determine, from a screening policy, at least one application to perform message processing on the signaling message at block 204.
  • decentralized process 200 may determine that message processing is not required for the signaling message and may route the message to its destination without performing any further message processing.
  • decentralized process 200 may modify the signaling message signaling message to include application routing information to allow the at least one application to complete signaling message routing.
  • the signaling message may be forwarded to the at least one application, and at block 210, the at least one application may route the signaling message using the application routing information. In this way, applications may, by use of decentralized process 200, complete signaling message routing without returning the signaling message to a screening module/function.
  • FIG. 3 illustrates an exemplary decentralized process 300 for processing signaling messages in a multi-application processing environment using a CDR and a LOP.
  • decentralized process 300 may wait for a signaling message to be received.
  • decentralized process 300 may determine whether the message is associated with an existing call by determining whether a CDR already exists for the call at decision point 304. If there is no existing CDR associated with the signaling message at decision point 304, a temporary CDR may be created at block 306 including call identification information from the message, and if a CDR does exist it may be referenced for the call associated with the message at block 308. In either case, decentralized process 300 may identify a screening policy to be applied to the message at block 310.
  • a screening policy may be stored in any storage medium suitable for access by a process such as decentralized process 300. As discussed above, these screening policies may include application processing and an order of application processing to be performed on the signaling message.
  • decentralized process 300 may determine from the screening policy a set of applications to process the signaling message and an associated sequence of processing.
  • Application point code (PC) addresses for the applications associated with this screening policy may be identified at block 314.
  • an LOP including application routing information may be created.
  • a message parameter may be modified at block 318 to allow application routing. For example, the LOP may be placed within a message field, such as a header field, to allow the LOP to be passed with the message.
  • the application point code of the first application to process the message may be inserted as the destination point code (DPC) of the message transfer part (MTP) routing label.
  • DPC destination point code
  • MTP message transfer part
  • the message may be routed to the first application at block 322.
  • application processing may begin by setting a dirty bit in the LOP associated with this application.
  • the message may be processed by the r application at block 326.
  • Message processing may include any message processing discussed above, such as prepaid, number portability, and usage measurements. Many other message processing procedures exist and all are considered within the scope of his subject matter described herein.
  • the application may determine whether there is another application at the current PC address to process the message. The application may do so by inspecting the LOP region associated with the next application. If there is another application at this point code to process the message, decentralized process 300 may return to block 324 for the second application processing at this point code and the process may repeat until all applications at the present point code have finished processing the signaling message.
  • the application may inspect the last application field in the LOP to determine if it is the last application to process the signaling message at decision point 330. If the current application is not the last application, the application may insert the PC address of the next application as the DPC of the MTP routing label for the signaling message at block 332.
  • this point code may be part of the LOP fields associated with the next application.
  • the application may route the signaling message to the next application and decentralized triggerless process 300 may transition to block 324 to repeat processing of the signaling message at the next application residing, this time, at a different PC address.
  • Decentralized process 300 will repeat the processing as described above for all applications at all point codes, as determined from the screening policy as described above and encoded in the LOP, until the last application is reached at decision point 330.
  • the last application may replace the original DPC stored in the LOP as the DPC of the MTP routing label of the signaling message at block 336.
  • the application may route the signaling message to the destination.
  • the signaling message was processed only once by a screening function rather than repeatedly after every application.
  • the signaling message was routed to the first application, which processed the message and routed the message within the network. All routing after the initial screening function routing to the first application was performed by the applications themselves. Applications may, by use of decentralized process 300, complete signaling message routing without returning the signaling message to a screening function. As well, as described above, both temporal and bandwidth savings may be realized.
  • Signaling message routing has been distributed to the signaling message processing applications rather than being centralized at a screening function.
  • Figure 4 illustrates an STP routing node, such as STP 102 including a screening system to identify application processing sequences for triggerless screening of signaling messages at applications.
  • STP 102 includes a high speed inter-processor message transport (IMT) communications bus 402.
  • IMT inter-processor message transport
  • processing modules or cards include a pair of maintenance and administration subsystem processors (MASP) 404, an SS7 link interface module (LIM) 406, an IP-capable data communication module (DCM) 408, a database services module (DSM) 410, and a screening module 412.
  • MASP maintenance and administration subsystem processors
  • LIM SS7 link interface module
  • DCM IP-capable data communication module
  • DSM database services module
  • These modules may be physically connected to the IMT bus 402 such that signaling and other types of messages may be routed internally between active cards or modules.
  • the distributed, multi-processor architecture of STP 102 facilitates the deployment of multiple LIM, DCM, DSM and other cards, all of which may be simultaneously connected to and communicating via IMT bus 402.
  • MASP pair 404 implement the maintenance and administration subsystem functions described above. As MASP pair 404 are not particularly relevant to a discussion of the flexible routing attributes of the present invention, a detailed discussion of their function is not provided herein.
  • LIM 406 interfaces with one or more external signaling links. LIM 406 may have a number of sub-components. In Figure 4, these sub-components include an SS7 MTP level 1 & 2 function 414, an SS7 MTP level 3 layer message discrimination function 416, a gateway screening (GWS) function 417, message distribution function 418, a routing function 420, and a signaling network management (NM) function 422.
  • GWS gateway screening
  • NM signaling network management
  • MTP level 1 and 2 function 414 provides the facilities necessary to send and receive digital data over a particular physical medium, as well as to provide error detection, error correction and sequenced delivery of SS7 messages.
  • Message discrimination function 416 receives signaling messages from the lower processing layers and performs a discrimination function that effectively determines whether an incoming SS7 message requires internal processing or is simply to be through switched. Examples of received SS7 messages that require internal processing include signaling connection control part messages in need of global title translation and signaling network management messages.
  • message distribution function 418 may receive such messages from discrimination function 416 and direct the messages to database services module 410 via IMT bus 402. This type of internal distribution of messages within the STP node should not be confused with message routing, which refers to selecting an external signaling link over which a received message should be forwarded.
  • Gateway screening function 417 may examine one or more parameters and signaling message and determine whether to allow the signaling message to pass into a network.
  • Conventional parameters examined by a gateway screening function include the destination point code of a received signaling message.
  • gateway screening function 417 may examine one or parameters of received ISUP messages to determine eligibility for processing by screening module 412 and by the associated applications. For example, as described above, if a redirection parameter and a received ISUP message corresponds to voicemail, gateway screening function 417 may forward the message to routing function 420 for routing, rather than to screening module 412 for further processing.
  • discrimination function 416 and/or gateway screening function 417 may first determine whether the messages are the type that require such screening. For example, discrimination function 416 or gateway screening function 417 may identify ISUP, SIP, TCAP, or other message types as candidates for screen by screening module 412. Discrimination function 416 or gateway screening function 417 may forward such messages to distribution module 418. Distribution module 418 may forward the messages to screening module 412 for further screening.
  • Routing function 420 is responsible for examining an incoming message and determining on which outbound linkset and link the message is to be transmitted. For example, routing function 420 may examine a destination point code in a received message, and perform a lookup in an MTP level 3 route table to select a route to the destination point code. Once route selection is made, routing function 420 ensures that the message is directed internally to the appropriate communication module (e.g., SS7 LIM, IP DCM, ATM high speed link (HSL), etc.) for outbound transmission.
  • the appropriate communication module e.g., SS7 LIM, IP DCM, ATM high speed link (HSL), etc.
  • MTP level 3 signaling network management function 422 may receive, process, and generate messages associated with the management and administration of an SS7 signaling network. NM function 422 may selectively communicate network management information to adjacent signaling points, so as to prevent the unwarranted sending of network management messages to nodes that are not affected by network failures.
  • database services module 410 includes a global title translation (GTT) function 424 and a routing function 426.
  • GTT function 424 may be used to translate digits present in a signaling message (e.g., an 800 number) to destination point codes (DPCs) and subsystem numbers (SSNs) to allow routing of these messages to the final destination.
  • Routing function 426 performs the same routing functions as those described above with respect to routing function 420. Once this determination is made, routing function 426 ensures that the message is directed internally to the appropriate communication module (e.g., SS7 LIM, IP DCM, ATM HSL, etc.) for outbound transmission.
  • the appropriate communication module e.g., SS7 LIM, IP DCM, ATM HSL, etc.
  • Screening module 412 may implement triggerless signaling message screening, as discussed above. By analyzing a signaling message, creating CDR and LOP structures, placing the LOP within the signaling message, and forwarding the signaling message to an application for processing and further routing at the application.
  • DCM 408 includes an IP transport function 428, a signaling protocol adaptation function 430, a discrimination function 432, a gateway screening function 433, a distribution function 434, and a routing function 436.
  • IP transport function 428 includes hardware and software for implementing OSI layers 1-3.
  • IP transport function may implement a physical layer protocol, such as Ethernet, a network layer protocol, such as IP, and a transport layer protocol, such as transmission control protocol (TCP), user datagram protocol (UDP), and/or stream control transmission protocol (SCTP).
  • TCP transmission control protocol
  • UDP user datagram protocol
  • SCTP stream control transmission protocol
  • Adaptation function 430 may receive a signaling message from an IP network that is formatted according to a first signaling protocol (e.g., M3UA, SUA, M2PA, TALI or other IP adaptation layer protocol), and adapt or reformat the message into a second signaling protocol (e.g., MTP). Adaptation function 430 may also receive a signaling message, such as a SIP message, and translate the SIP message into an equivalent SS7 or SS7-adaptation protocol message, and vice-versa. These adaptation and translation processing operations may be performed on in-bound and out-bound signaling messages. Adaptation function 430 may also receive outbound SS7 messages from other modules in STP 102 and modify the messages for transport over the IP network according to the appropriate signaling transport or other IP adaptation layer protocol.
  • a first signaling protocol e.g., M3UA, SUA, M2PA, TALI or other IP adaptation layer protocol
  • MTP second signaling protocol
  • Adaptation function 430 may also receive a signaling message, such
  • Discrimination function 432 performs discrimination operations similar to those described above with respect to discrimination function 416. In addition to the SS7 and SS7-adaptation protocol discrimination parameters described above, discrimination function 432 may also examine received SIP message parameters including a To parameter, a From parameter, a Via parameter, a source IP address parameter, a destination IP address parameter, and others. Discrimination based on these parameters enables function 432 to determine whether screening or internal processing is required. According to one embodiment, discrimination function 432 may copy a received signaling message, such that the original message may be routed to the target destination and the message copy may be processed by one or more processing subsystems associated with STP 102.
  • Gateway screening function 433 may perform operations similar to gateway screening function 417 to determine eligibility for screening of received messages by screening module 412. For example, gateway screening function 433 may analyze one or more parameters and receive ISUP messages to determine whether the ISUP messages are eligible for screening. If messages are eligible for screening, gateway screening function 433 and/or discrimination function 432 may forward such messages to distribution function 434. Distribution function 434 may forward such messages to screening module 412 for screening.
  • Distribution function 434 handles the internal routing of message packets that require additional processing prior to final routing.
  • Such messages may include signaling messages associated with message service messages such as SMS, MMS, and IM services (e.g., SIP INFO message, SIP MESSAGE message, SIP INVITE message, etc.), as well as mobility management messages.
  • Routing function 436 is adapted to access network routing rule information, which may include SS7 and IP network routing rules, and apply these routing rules to messages that require routing.
  • Figure 5 illustrates an exemplary application, such as prepaid application 106 for decentralized routing of a signaling message.
  • signaling message 118 arrives at prepaid application 106, it may first be processed by message routing module 502.
  • Message routing module 502 may inspect the LOP within the message and set the dirty bit within the LOP for the prepaid application at this point code.
  • Message routing module 502 may then forward the message to prepaid processing module 504 for message processing.
  • Message processing may include modifications to the message itself or service tracking, such as billing and other activities, as discussed above.
  • database 506 may be used to store application processing routines and data, and tracking data structures.
  • Prepaid processing module 504 may retrieve processing routines and data from database 506 and may store any tracking details that are associated with this message to database 506.
  • prepaid processing module 504 may return the message to message routing module 502, which may determine whether there is another application at this point code, which as discussed above, will yield a negative result in this embodiment.
  • message routing module 502 may inspect the LOP to determine whether it is the last application to process the signaling message. In this exemplary embodiment, there are other applications that need to process the signaling message. Accordingly, message routing module 502 may insert the point code of the next application as the MTP routing label for the message and route the message as signaling message 120 to the next application.
  • the subject matter described herein allows a message to be screened once, processed by one or more applications, routed among the applications using application routing information inserted by the screening function, and then routed to a destination.
  • the processing performed by the screening function and the applications may be triggerless processing in the case of ISUP messages sent between end offices.
  • the processing may be triggered processing in the case of processing TCAP messages sent by an end office to a signaling message routing node for processing.

Abstract

Disclosed are methods, systems, and computer program products for decentralized triggerless processing of signaling messages in a multi-application processing environment. According to one method, a signaling message is received at a screening module. At least one application to perform message processing on the signaling message is determined from a screening policy. The signaling message is modified to include application routing information to allow the at least one application to complete signaling message routing. The signaling message is forwarded to, and routed by, the at least one application using the application routing information.

Description

DESCRIPTION
METHODS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR DECENTRALIZED PROCESSING OF SIGNALING MESSAGES IN A
MULTI-APPLICATION PROCESSING ENVIRONMENT
RELATED APPLICATIONS
This application claims the benefit of U.S. Provisional Patent Application Serial No. 60/757,297, filed January 9, 2006 and U.S. Patent Application Serial No. 11/392,241 , filed March 29, 2006; the disclosures of which are incorporated herein by reference in their entireties.
TECHNICAL FIELD
The subject matter described herein relates to processing signaling messages. More particularly, the subject matter described herein relates to methods, systems, and computer program products for decentralized processing of signaling message in a multi-application processing environment.
BACKGROUND Signaling messages are used within communications networks to communicate information related to call setup, call tear down, call timing, billing, messaging and many related functions. Signaling messages are processed by various applications to achieve the desired functions. Examples of signaling message processing include triggerless processing of ISDN user part (ISUP), telephone user part (TUP), transaction capabilities application part (TCAP), mobile application part (MAP) and session initiation protocol (SIP) signaling messages in a multi-application environment. Some of the message types, such as ISUP and SIP messages relating to call setup, may be subjected to triggerless processing by a signaling message routing node. "Triggerless processing," as used herein, refers to the processing of a received signaling message without requiring an end office trigger to initiate the processing. For example, a signal transfer point (STP) may perform triggerless processing of received ISUP IAM messages requiring local number portability (LNP) lookups by performing LNP database lookups for the IAM messages without requiring end office trigger to initiate the lookups. Another example of triggerless processing that may be performed for received signaling messages includes screening. For example, received ISUP messages may be screened based on one or more parameters in each message and either routed to their respective destinations, or blocked, depending on the results of the screening.
Signaling messages are routed in communications networks through network elements for processing. Some examples of these network elements include an STP, a signaling system number 7 (SS7) Internet protocol (IP) signaling gateway (SG) (collectively SS7-IP SG), an SS7 gateway, a SIP server, a short message gateway (SMG)1 a Softswitch (SS), and a media gateway controller (MGC).
When a signaling message is routed, the signaling message may be routed through and by any of these network elements. Some network elements may include screening functions or modules (hereinafter referred to as screening functions). Screening functions have traditionally been adapted to apply a screening policy to a received signaling message and to route the signaling message after the screening policy has been applied. Screening policies may include a variety of processing tasks for any given signaling message. These processing tasks may include processing by one or more message processing applications. Example message processing applications include triggerless pre-paid service applications, number portability service applications, location portability service applications, usage measurements service applications, billing service applications, advanced / intelligent routing service applications (e.g., time of day routing, etc.), messaging service applications (e.g., short message service, multimedia message service, instant message service, etc.), presence service, ENUM service, and other signaling message-based network service applications. Traditionally, screening policies have been implemented by screening functions that manage all aspects of the processing. These screening functions have acted as a cog in a wheel by placing themselves logically in the middle of several processing applications and sequentially sending signaling messages to applications one at a time for processing (as if sending them along the spokes of the wheel to each application). When signaling message processing is completed by any given application, the message is then sent by the application back to the screening function. The screening function then determines, based upon the screening policy, which application should process the message next and sends the message to that application. This repeats until all message processing is completed and the message is received back at the screening function. With the screening policy complete, the screening function may then route the signaling message to the next node in the network.
By handling all processing and routing decisions for every message, screening functions have traditionally managed all aspects of signaling message processing and routing. The traditional approach burdens the screening function with repeated message processing and routing tasks. This repeated processing burden consumes valuable signaling link bandwidth and requires a substantial amount of time.
For example, the SS7 signaling protocol includes various call setup timers that effectively limit the delays that' can be incurred between network elements during call setup operations. Each time a signaling message is routed to the screening function and the screening function has to receive and process the message, an element of time delay is introduced. This repeated processing by a screening function may cause the maximum latency permitted by the SS7 ISUP call setup timers to be exceeded.
Bandwidth is also consumed on the order of 2N (where N is the number of applications). To clarify, for each application required to implement a given screening policy, two transmissions of the message occur: one- from the screening function to the application; and another from the application back to the screening function.
Accordingly, in light of these difficulties associated with conventional message screening, there exists a need for improved methods, systems, and computer program products for screening policy implementation. SUMMARY
According to one aspect, the subject matter described herein comprises methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment. One method includes receiving a signaling message at a screening module, determining, from a screening policy, at least one application to perform triggerless message processing on the signaling message, modifying the signaling message to include application routing information to allow the at least one application to complete signaling message routing, forwarding the signaling message to the at least one application, and, at the at least one application, routing the signaling message using the application routing information. By "complete signaling message routing," it is meant that the screening function inserts sufficient routing information in the message for the applications to forward the signaling message between applications designated to process the message without requiring the message to go back to the screening function, and, if the message passes all of the application processing, for forwarding the message to a destination without going back to the screening function.
The subject matter described herein providing decentralized processing of signaling messages in a multi-application processing environment may be implemented using a computer program product comprising computer executable instructions embodied in a computer readable medium. Exemplary computer readable media suitable for implementing the subject matter described herein include disk memory devices, chip memory devices, programmable logic devices, application specific integrated circuits, and downloadable electrical signals. In addition, a computer readable medium that implements the subject matter described herein may be distributed across multiple physical devices and/or computing platforms. BRIEF DESCRIPTION OF THE DRAWINGS
Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings of which:
Figure 1 is block diagram of an exemplary system for decentralized processing of signaling messages in a multi-application processing environment according to an embodiment of the subject matter described herein;
Figure 2 is a flow chart illustrating exemplary steps by which decentralized processing of signaling messages in a multi-application processing environment may be performed according to an embodiment of the subject matter described herein;
Figure 3 is a flow chart illustrating exemplary steps by which decentralized processing of signaling messages in a multi-application processing environment may be performed using a call detail record (CDR) and a list of parameters (LOP) according to an embodiment of the subject matter described herein;
Figure 4 is block diagram of an exemplary signaling transfer point (STP) including a screening module to identify application processing sequences for screening of signaling messages at applications according to an embodiment of the subject matter described herein; and
Figure 5 is block diagram of an exemplary application for decentralized triggerless routing of a signaling message according to an embodiment of the subject matter described herein.
DETAILED DESCRIPTION
As the available number of subscriber services increase over time, the number of message screening and service tracking activities will increase as well. As a result, the delays and bandwidth consumption associated with message screening are also likely to increase. With each new consumer service and associated tracking correlating, potentially, to one or more new signaling message processing applications, a new approach to signaling message screening has become desirable to reduce message routing and processing latency. In view of the burdens described above with respect to centralized message screening routing at a message screening function, the subject matter described herein distributes the responsibility of message routing to the applications that actually perform the screening. Where previously, a screening function was responsible for all routing activity (a cog in a wheel), the present subject matter includes methods, systems, and computer program products for decentralized processing of signaling message in a multi-application processing environment. By adapting the screening function and screening applications to process routing information differently, bandwidth and temporal savings may be achieved.
Figure 1 illustrates an exemplary decentralized processing system 100 for decentralized triggerless processing of signaling messages in a multi- application processing environment. For this exemplary embodiment, an SS7 network environment will be discussed. Many other network environments are capable of implementing a screening function, such as, for example, an Internet protocol (IP) based network. Accordingly, all other such networks are considered within the scope of the present subject matter. As discussed above, exemplary network elements within an SS7 network include, for example, a signal transfer point (STP), an SS7-IP signaling gateway (SG), a short message gateway (SMG), a Softswitch (SS) or media gateway controller (MGC). Exemplary network elements within an IP network include, for example, a SIP proxy server, an IP multimedia subsystem (IMS) call state control function (CSCF) element, and a SIP messaging server. In the illustrated example, decentralized processing system 100 includes an STP 102, a signaling message screening function 104, a prepaid application 106, a number portability application 108 and a usage measurements application 110. In this embodiment, an SS7 ISUP call setup message 112 may be received at STP 102 and directed to signaling message screening function 104 as ISUP message 114. Call setup message 114 may include signaling message parameters derived from call setup message 112, as will be described below. Screening function 104 may be internal to, co-located with, or external to STP 102. Screening function 104 may have access to any appropriate storage device capable of storing databases, tables, or other data structures used by screening function 104. In operation, screening function 104 may receive ISUP message 114 and apply a screening policy or screening rule to the message. As described above, signaling message parameters may be included within ISUP message 114 and may be used to identify, evaluate and determine the screening policy or rules to be applied, including the sequence of application processing. For example, signaling message parameters used by screening function 104 may include an origination point code (OPC), a destination point code (DPC), a circuit identification code (CIC), a signaling indicator (Sl), a message type, a called party number (CdPN), a calling party number (CgPN), and a carrier ID.
In one example, screening function 104 or a gateway screening function within STP 102 may make an initial determination as to whether a message is eligible for processing by one or more applications, such as applications 106, 108, and 110. In order to determine eligibility for application processing, screening function 104 or a gateway screening function within STP 102 may analyze one or more parameters in a message. For example, if the message is an ISUP message, screening function 104 or a gateway screening function within STP 102 may analyze the redirection number in the ISUP message to determine whether a call associated with the message is being directed to voicemail. If the redirection number indicates a voicemail number, it may not be necessary to perform any application processing of the message. Accordingly, the message may be routed to its destination rather than being screened. In another example, it may be desirable to analyze other ISUP parameters, such as OPC/DPC/CIC, and redirect a message to a specific service, such as prepaid service, in a manner that bypasses further screening or multi-application routing. Screening policies of screening function 104 may be used to implement, for example, intelligent network (IN) and advance IN (AIN) features on behalf of an end office in the form of a proxy service. Screening rules implemented by screening function 104 may dictate that ISUP messages satisfying certain screening criteria should be processed by one or more message processing applications. Further, screening rules implemented by screening function 104 may specify a desired sequence of processing for the message processing applications.
For example, a screening rule implemented by screening function 104 may require that an ISUP IAM message associated with a call to (212) 450- 1023 should be first processed by a pre-paid calling service application, then processed by a number portability application, and then processed by a usage measurements application. An exemplary screening rule, as described, is shown in Table 1 where the asterisk indicates that the rule depicted may apply to any called party within area code "212" and exchange "450."
Figure imgf000010_0001
Table 1: Exemplary Screening Rule
Screening function 104 may also include a data structure which maps application identifiers to SS7 point code addresses associated with screening applications. An exemplary data structure is shown in Table 2.
Figure imgf000010_0002
Table 2: Exemplary Application Point Code Data Structure
Continuing with the discussion of Figure 1 , when ISUP message 114 is received at screening function 104, screening function 104 may identify the appropriate screening rule for the call. The exemplary screening rule of Table
1 will be used as the desired screening rule for the processing of ISUP message 114. Based upon the screening rule depicted in Table 1 , screening function 104 may generate or instantiate data structures to assist with processing of ISUP message 114. The first may be a temporary call detail record (CDR) or a stateful CDR-like data structure that may include information extracted from ISUP message 114. This temporary CDR may be used to identify the call or call state, respectively. For example, a temporary CDR may include OPC1 DPC and CIC information, which identifies the call associated with ISUP call setup message 112 and ISUP message 114, as illustrated in Table 3.
Figure imgf000011_0001
Table 3: Exemplary CDR Data Structure
The temporary CDR may be used by screening function 104 to identify and correlate subsequent ISUP messages (e.g., subsequent address message, address complete, answer, release complete, etc.) that are associated with the same call. The temporary CDR may also include information which identifies applications to which previous messages related to the same call were sent for processing. With the screening rule identified and the CDR instantiated, screening function 104 may then create ISUP message 116 by modifying ISUP message 114 to include application routing information. This application routing information may identify both the applications that are to process the message and the desired sequence of processing. One approach to including routing information within ISUP message 116 may be to create a routing data structure, described herein as a List Of Pointcodes (LOP). Once created, this LOP may be included within ISUP message 116 as a routing parameter. There are many other possible ways to include routing information within ISUP message 116 and all are considered within the scope of this subject matter described herein. For simplicity, only the LOP will be discussed in detail. An LOP structure may include any of the following fields: an Application Point Code field, an Application ID field, a Last Application field, and a Dirty Bit field. An exemplary LOP for use with ISUP message 116 is shown in Table 4.
Figure imgf000012_0001
Table 4: Exemplary LOP
In Table 4, the Application Point Code field may include point codes for applications that are to process ISUP message 116. The Application ID field may include a character string or numeric representation of an application identifier. The Last Application field may include a binary indicator that may be set for the application that is to process ISUP message 116 last. The Dirty Bit field may include a binary indicator that may be set by each application sequentially as each processes ISUP message 116. It should be noted that the original DPC of ISUP call setup message 112 has been included in this exemplary LOP as the last application ID. Placement of the original DPC as the last application ID allows preservation of the original DPC within the ISUP message and facilitates routing by the last application to the final destination. This process will be discussed in more detail below. The routing and, consequently, the application processing of ISUP message 116 may follow the order in which applications are identified within the LOP. As discussed above, this routing sequence specified within the exemplary LOP should result in routing first to prepaid application 106, then to number portability application 108, and finally to usage measurements application 110.
It should be noted that applications may be identified within the LOP with both a point code and an application ID. Situations may arise wherein multiple applications may reside at the same point code. In situations such as these, the Application ID may be used by the network element to identify the intended applications at that point code address, and the order within the LOP may still be used to indicate the processing sequence for those applications at the same point code address. Further, in reference to a data structure that may be used to implement the exemplary LOP of Table 4, the application ID may be a binary value, a hexadecimal value, a character string, or any other encoding format. The SS7 point code addresses may be a 24-bit American National Standards Institute (ANSI) format, a 14-bit International Telecommunication Union (ITU) format, or any other appropriate format for point code addresses.
The last application identified to process the ISUP message, which in the present embodiment is usage measurements application 110, has its Last App bit set to a value of 1. As discussed above, the original DPC parameter value contained in ISUP message 116 may be included as the last entry in the LOP. Details of the use of these fields for processing the ISUP message will be discussed in more detail below.
Returning again to Figure 1, screening function 104 may create ISUP message 116 by inserting the LOP parameter in ISUP message 114. The LOP may be placed in any location that is appropriate for a given protocol. Screening function 104 may then set the DPC field of the message transfer part (MTP) routing label of ISUP message 116 to the DPC of prepaid application 106, which in this example is the first application identified to process ISUP message 116. Screening function 104 may then forward ISUP message 116 to prepaid application 106 by way of STP 102. STP 102 may forward ISUP message 116 to prepaid application 106 as ISUP message 118.
ISUP message 118 may be received by prepaid application 106 and processing of the prepaid application task may begin. As part of the processing, prepaid application 106 may perform several operations. It may change the dirty bit to "1 ," thereby representing to subsequent applications that prepaid application 106 has processed the ISUP message.
If the application is stateful, so that it may process a message more than once, for example, initially and then again after forwarding the message to another application or applications for other processing, it may keep a copy of the list of point codes to allow it to further operate on the message at a future time. Discussion of this stateful operation will be limited herein for purposes of simplicity. It should be sufficient to note that stateful processing of messages may be achieved by maintenance . of processing sequences within an application so that subsequent operations may be performed by an application after processing is completed by another application or applications.
Likewise, as described above for the case of multiple applications at the same point code, an application may analyze all point code entries in the LOP of a received message to determine whether the next application resides at the same point code. If the next application is present at the same point code, the application ID field may be used to indicate the order of processing. Again, for simplicity, the present embodiment will be described with only one application at each point code.
With the order of local application processing determined, prepaid application 106 may complete its operations on ISUP message 118. It may then analyze the LOP to determine whether it is the last application to process the ISUP message by inspecting the last application bit. Determining that it is not the last application, prepaid application 106 may then look up the first point code in the LOP parameter whose dirty bit is set to a "0." Prepaid application 106 may then insert that point code as the DPC of the MTP routing label and may forward ISUP message 120 to the next application, which, in this exemplary embodiment, is number portability application 108.
When ISUP message 120 is received by number portability application 108, number portability processing may be performed, the dirty bit may be set, the LOP parameter may be analyzed to locate the next point code, and the next point code may be inserted in the DPC of the MTP routing label. Number portability application 108 may then forward ISUP message 122 to usage measurements application 110 with the DPC of usage measurements application 110 as the DPC of the MTP routing label. Usage measurements application 110 may collect one or more measurements for ISUP message 122 and examine the LOP parameter to locate the next application. In this example, usage measurements application 110 may recognize that it is the last application by inspection of the last application field in the LOP. It may also recognize that all other application dirty bits are set. Usage measurements application 110 may then replace the DPC of the MTP routing label with the original DPC included as the last entry of the LOP. Usage measurements application 110 may then forward ISUP message 124 to STP 102 with all application processing completed.
Upon receipt of ISUP message 124 at STP 102, normal processing may continue and STP 102 may forward ISUP message 126 to the final destination indicated by the original DPC.
As described above, screening function 104 is only required to process the original message one time. The 2N routing bandwidth requirements for traditional message screening architectures may be reduced to as little as 1 N, again where N is the number of applications to process a given message. Latency may also be reduced as a function of at least two variables: processing time and transmission time. The reduction in processing time represents a savings over the processing time previously associated with traditional message screening where the screening function processed each message after every application processing event. The reduction in transmission time represents a savings over the transmission time previously associated with the multiple message returns to the screening function. These improvements over traditional message screening architectures also may provide performance enhancement by reducing state machine complexity within a screening function. System maintenance and upgrade may also be enhanced by allowing applications to be added with minimal updates to the screening function. Static tables of available applications and feature processing sequences could be downloaded to the screening function without extensive provisioning or recompilation. Other aspects and performance enhancements are possible. Accordingly, all such enhancements are considered within scope of the present subject matter.
The example described above relates to an SS7 ISUP message. Alternatively, for example, a transaction capabilities application part (TCAP) message may be processed as a query in response to an end office trigger. As well, a telephone user part (TUP) message may be processed. Many other types of messages may be processed using the description herein and all such processing is considered within the scope of the subject matter described herein.
In an alternate example, the present subject matter may include processing IP telephony signaling messages, such as SIP signaling messages. In one processing example, a SIP INVITE message may be intercepted at a network routing node, such as a SIP - SS7 Gateway or a SIP server, and directed to a screening function, in a manner similar to that described above with respect to an SS7 ISUP implementation. The screening function may include screening policies or screening rules associated with SIP signaling and SIP users. An exemplary SIP screening rule is illustrated in Table 5.
Figure imgf000016_0001
Table 5: Exemplary SIP Screening Rules
Screening rules may indicate that SIP messages satisfying certain screening criteria should be processed by one or more message processing applications. The screening function may also include a data structure, which maps application identifiers to SIP or IP addresses associated with the applications, such as those illustrated in Table 6.
Figure imgf000016_0002
Table 6: Exemplary Application ID/Address Information
A SIP screening function may be adapted, for example, to create a temporary CDR or a stateful CDR-like data structure, similar to that discussed above, that includes information extracted from the SIP INVITE message, and which may identify the call or call state for the message, respectively. For example, a temporary CDR may include Call-ID information which may identify a call, as illustrated in Table 7. This temporary CDR may be used by the screening function to identify and correlate subsequent SIP messages that are associated with the same call. The temporary CDR may also contain information which identifies to which applications previous messages related to the same call were sent for processing.
Figure imgf000017_0001
Table 7: Exemplary CDR and Call State Information
Having determined which applications are designated within the screening rules to process the SIP INVITE message, the screening function may modify the SIP INVITE message to include information that identifies both the message processing applications to process the message and the sequence in which these applications should route the message. This may, for example, be accomplished using SIP ROUTE and VIA parameters in the header of the SIP INVITE message.
A SIP ROUTE header parameter may be used to identify the address of a first message processing application to which the message should be routed. Multiple ROUTE header parameters may be used with each identifying the address of a message processing application to sequentially process the message. The ROUTE parameter(s) may be included in the INVITE message, and the INVITE message may then be routed from the screening function to the first message processing application. Message processing may occur at the first application, as discussed above, and the INVITE message may then be routed by each application to the next for subsequent processing until all applications represented in the sequence of ROUTE parameters have processed the message.
If a message processing application needs to receive or "touch" a subsequent response message associated with the INVITE message, the message processing application may insert it's address in a VIA parameter of the INVITE message before routing it on to the next application. In this manner, the message processing application may receive all subsequent response messages associated with the INVITE. This may be accomplished based upon the SIP principle that response message return through addresses specified in the VIA parameter(s) of the INVITE message. Multiple VIA parameters may be included in the SIP INVITE header to allow multiple applications to receive response messages.
Accordingly, SIP systems may use decentralized triggerless message processing as discussed herein to obtain temporal and bandwidth savings as discussed above. Many other signaling systems exist and all are considered within the scope of the subject matter described herein. Figure 2 illustrates an exemplary decentralized process 200 for processing signaling messages in a multi-application processing environment. A block 202, decentralized process 200 may receive a signaling message at a screening module. Decentralized process 200 may determine, from a screening policy, at least one application to perform message processing on the signaling message at block 204. Alternatively, as described above, decentralized process 200 may determine that message processing is not required for the signaling message and may route the message to its destination without performing any further message processing. At block 206, decentralized process 200 may modify the signaling message signaling message to include application routing information to allow the at least one application to complete signaling message routing. At block 208, the signaling message may be forwarded to the at least one application, and at block 210, the at least one application may route the signaling message using the application routing information. In this way, applications may, by use of decentralized process 200, complete signaling message routing without returning the signaling message to a screening module/function.
Figure 3 illustrates an exemplary decentralized process 300 for processing signaling messages in a multi-application processing environment using a CDR and a LOP. At decision point 302, decentralized process 300 may wait for a signaling message to be received. When a message is received, decentralized process 300 may determine whether the message is associated with an existing call by determining whether a CDR already exists for the call at decision point 304. If there is no existing CDR associated with the signaling message at decision point 304, a temporary CDR may be created at block 306 including call identification information from the message, and if a CDR does exist it may be referenced for the call associated with the message at block 308. In either case, decentralized process 300 may identify a screening policy to be applied to the message at block 310.
A screening policy may be stored in any storage medium suitable for access by a process such as decentralized process 300. As discussed above, these screening policies may include application processing and an order of application processing to be performed on the signaling message. A block 312, decentralized process 300 may determine from the screening policy a set of applications to process the signaling message and an associated sequence of processing. Application point code (PC) addresses for the applications associated with this screening policy may be identified at block 314. At block 316, an LOP including application routing information may be created. A message parameter may be modified at block 318 to allow application routing. For example, the LOP may be placed within a message field, such as a header field, to allow the LOP to be passed with the message. At block 320, the application point code of the first application to process the message may be inserted as the destination point code (DPC) of the message transfer part (MTP) routing label.
The message may be routed to the first application at block 322. At block 324, application processing may begin by setting a dirty bit in the LOP associated with this application. The message may be processed by the r application at block 326. Message processing may include any message processing discussed above, such as prepaid, number portability, and usage measurements. Many other message processing procedures exist and all are considered within the scope of his subject matter described herein.
At decision point 328, the application may determine whether there is another application at the current PC address to process the message. The application may do so by inspecting the LOP region associated with the next application. If there is another application at this point code to process the message, decentralized process 300 may return to block 324 for the second application processing at this point code and the process may repeat until all applications at the present point code have finished processing the signaling message.
When all applications at the present point code have completed processing the signaling message at decision point 328, the application may inspect the last application field in the LOP to determine if it is the last application to process the signaling message at decision point 330. If the current application is not the last application, the application may insert the PC address of the next application as the DPC of the MTP routing label for the signaling message at block 332.
As described above, this point code may be part of the LOP fields associated with the next application. At block 334, the application may route the signaling message to the next application and decentralized triggerless process 300 may transition to block 324 to repeat processing of the signaling message at the next application residing, this time, at a different PC address.
Decentralized process 300 will repeat the processing as described above for all applications at all point codes, as determined from the screening policy as described above and encoded in the LOP, until the last application is reached at decision point 330. When the last application has finished its processing, it may replace the original DPC stored in the LOP as the DPC of the MTP routing label of the signaling message at block 336. At block 338, the application may route the signaling message to the destination.
As described above in relation to decentralized process 300, the signaling message was processed only once by a screening function rather than repeatedly after every application. The signaling message was routed to the first application, which processed the message and routed the message within the network. All routing after the initial screening function routing to the first application was performed by the applications themselves. Applications may, by use of decentralized process 300, complete signaling message routing without returning the signaling message to a screening function. As well, as described above, both temporal and bandwidth savings may be realized. Signaling message routing has been distributed to the signaling message processing applications rather than being centralized at a screening function. Figure 4 illustrates an STP routing node, such as STP 102 including a screening system to identify application processing sequences for triggerless screening of signaling messages at applications. In Figure 4, STP 102 includes a high speed inter-processor message transport (IMT) communications bus 402. A number of distributed processing modules or cards may be coupled to IMT bus 402. In Figure 4, these processing modules or cards include a pair of maintenance and administration subsystem processors (MASP) 404, an SS7 link interface module (LIM) 406, an IP-capable data communication module (DCM) 408, a database services module (DSM) 410, and a screening module 412. These modules may be physically connected to the IMT bus 402 such that signaling and other types of messages may be routed internally between active cards or modules. The distributed, multi-processor architecture of STP 102 facilitates the deployment of multiple LIM, DCM, DSM and other cards, all of which may be simultaneously connected to and communicating via IMT bus 402.
MASP pair 404 implement the maintenance and administration subsystem functions described above. As MASP pair 404 are not particularly relevant to a discussion of the flexible routing attributes of the present invention, a detailed discussion of their function is not provided herein. LIM 406 interfaces with one or more external signaling links. LIM 406 may have a number of sub-components. In Figure 4, these sub-components include an SS7 MTP level 1 & 2 function 414, an SS7 MTP level 3 layer message discrimination function 416, a gateway screening (GWS) function 417, message distribution function 418, a routing function 420, and a signaling network management (NM) function 422.
MTP level 1 and 2 function 414 provides the facilities necessary to send and receive digital data over a particular physical medium, as well as to provide error detection, error correction and sequenced delivery of SS7 messages. Message discrimination function 416 receives signaling messages from the lower processing layers and performs a discrimination function that effectively determines whether an incoming SS7 message requires internal processing or is simply to be through switched. Examples of received SS7 messages that require internal processing include signaling connection control part messages in need of global title translation and signaling network management messages.
For SCCP messages that require GTT processing by database services module 410, message distribution function 418 may receive such messages from discrimination function 416 and direct the messages to database services module 410 via IMT bus 402. This type of internal distribution of messages within the STP node should not be confused with message routing, which refers to selecting an external signaling link over which a received message should be forwarded.
Gateway screening function 417 may examine one or more parameters and signaling message and determine whether to allow the signaling message to pass into a network. Conventional parameters examined by a gateway screening function include the destination point code of a received signaling message. According to one implementation of the subject matter described herein, gateway screening function 417 may examine one or parameters of received ISUP messages to determine eligibility for processing by screening module 412 and by the associated applications. For example, as described above, if a redirection parameter and a received ISUP message corresponds to voicemail, gateway screening function 417 may forward the message to routing function 420 for routing, rather than to screening module 412 for further processing.
In order to identify messages as candidates for screening by screening module 412, discrimination function 416 and/or gateway screening function 417 may first determine whether the messages are the type that require such screening. For example, discrimination function 416 or gateway screening function 417 may identify ISUP, SIP, TCAP, or other message types as candidates for screen by screening module 412. Discrimination function 416 or gateway screening function 417 may forward such messages to distribution module 418. Distribution module 418 may forward the messages to screening module 412 for further screening.
Routing function 420 is responsible for examining an incoming message and determining on which outbound linkset and link the message is to be transmitted. For example, routing function 420 may examine a destination point code in a received message, and perform a lookup in an MTP level 3 route table to select a route to the destination point code. Once route selection is made, routing function 420 ensures that the message is directed internally to the appropriate communication module (e.g., SS7 LIM, IP DCM, ATM high speed link (HSL), etc.) for outbound transmission.
MTP level 3 signaling network management function 422 may receive, process, and generate messages associated with the management and administration of an SS7 signaling network. NM function 422 may selectively communicate network management information to adjacent signaling points, so as to prevent the unwarranted sending of network management messages to nodes that are not affected by network failures.
As illustrated in Figure 4, database services module 410 includes a global title translation (GTT) function 424 and a routing function 426. If GTT processing is needed, GTT function 424 may be used to translate digits present in a signaling message (e.g., an 800 number) to destination point codes (DPCs) and subsystem numbers (SSNs) to allow routing of these messages to the final destination. Routing function 426 performs the same routing functions as those described above with respect to routing function 420. Once this determination is made, routing function 426 ensures that the message is directed internally to the appropriate communication module (e.g., SS7 LIM, IP DCM, ATM HSL, etc.) for outbound transmission.
Screening module 412 may implement triggerless signaling message screening, as discussed above. By analyzing a signaling message, creating CDR and LOP structures, placing the LOP within the signaling message, and forwarding the signaling message to an application for processing and further routing at the application.
DCM 408 includes an IP transport function 428, a signaling protocol adaptation function 430, a discrimination function 432, a gateway screening function 433, a distribution function 434, and a routing function 436. IP transport function 428 includes hardware and software for implementing OSI layers 1-3. For example, IP transport function may implement a physical layer protocol, such as Ethernet, a network layer protocol, such as IP, and a transport layer protocol, such as transmission control protocol (TCP), user datagram protocol (UDP), and/or stream control transmission protocol (SCTP). Adaptation function 430 may receive a signaling message from an IP network that is formatted according to a first signaling protocol (e.g., M3UA, SUA, M2PA, TALI or other IP adaptation layer protocol), and adapt or reformat the message into a second signaling protocol (e.g., MTP). Adaptation function 430 may also receive a signaling message, such as a SIP message, and translate the SIP message into an equivalent SS7 or SS7-adaptation protocol message, and vice-versa. These adaptation and translation processing operations may be performed on in-bound and out-bound signaling messages. Adaptation function 430 may also receive outbound SS7 messages from other modules in STP 102 and modify the messages for transport over the IP network according to the appropriate signaling transport or other IP adaptation layer protocol.
Discrimination function 432 performs discrimination operations similar to those described above with respect to discrimination function 416. In addition to the SS7 and SS7-adaptation protocol discrimination parameters described above, discrimination function 432 may also examine received SIP message parameters including a To parameter, a From parameter, a Via parameter, a source IP address parameter, a destination IP address parameter, and others. Discrimination based on these parameters enables function 432 to determine whether screening or internal processing is required. According to one embodiment, discrimination function 432 may copy a received signaling message, such that the original message may be routed to the target destination and the message copy may be processed by one or more processing subsystems associated with STP 102.
Gateway screening function 433 may perform operations similar to gateway screening function 417 to determine eligibility for screening of received messages by screening module 412. For example, gateway screening function 433 may analyze one or more parameters and receive ISUP messages to determine whether the ISUP messages are eligible for screening. If messages are eligible for screening, gateway screening function 433 and/or discrimination function 432 may forward such messages to distribution function 434. Distribution function 434 may forward such messages to screening module 412 for screening.
Distribution function 434 handles the internal routing of message packets that require additional processing prior to final routing. Such messages may include signaling messages associated with message service messages such as SMS, MMS, and IM services (e.g., SIP INFO message, SIP MESSAGE message, SIP INVITE message, etc.), as well as mobility management messages. Routing function 436 is adapted to access network routing rule information, which may include SS7 and IP network routing rules, and apply these routing rules to messages that require routing.
Figure 5 illustrates an exemplary application, such as prepaid application 106 for decentralized routing of a signaling message. When signaling message 118 arrives at prepaid application 106, it may first be processed by message routing module 502. Message routing module 502 may inspect the LOP within the message and set the dirty bit within the LOP for the prepaid application at this point code. As discussed above, there may be more than one application at a given point code. For this exemplary embodiment, only one application resides at this point code.
Message routing module 502 may then forward the message to prepaid processing module 504 for message processing. Message processing may include modifications to the message itself or service tracking, such as billing and other activities, as discussed above. To aid prepaid processing module 504 in message processing and service tracking, database 506 may be used to store application processing routines and data, and tracking data structures. Prepaid processing module 504 may retrieve processing routines and data from database 506 and may store any tracking details that are associated with this message to database 506.
When message processing is complete, prepaid processing module 504 may return the message to message routing module 502, which may determine whether there is another application at this point code, which as discussed above, will yield a negative result in this embodiment. Message routing module 502 may inspect the LOP to determine whether it is the last application to process the signaling message. In this exemplary embodiment, there are other applications that need to process the signaling message. Accordingly, message routing module 502 may insert the point code of the next application as the MTP routing label for the message and route the message as signaling message 120 to the next application. Thus, as described above, rather than requiring that a message be forwarded back and forth multiple times between processing applications and a screening function, the subject matter described herein allows a message to be screened once, processed by one or more applications, routed among the applications using application routing information inserted by the screening function, and then routed to a destination. The processing performed by the screening function and the applications may be triggerless processing in the case of ISUP messages sent between end offices. In addition, the processing may be triggered processing in the case of processing TCAP messages sent by an end office to a signaling message routing node for processing. It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.

Claims

CLAIMSWhat is claimed is:
1. A method for decentralized processing of signaling messages in a multi- application processing environment, the method comprising: (a) receiving a signaling message at a screening module;
(b) determining, from a screening policy, at least one application to perform message processing on the signaling message;
(c) modifying the signaling message to include application routing information to allow the at least one application to complete signaling message routing;
(d) forwarding the signaling message to the at least one application; and
(e) at the least one application, routing the signaling message using the application routing information.
2. The method of claim 1 wherein receiving the signaling message includes receiving a message selected from a group consisting of an ISDN user part (ISUP) message, a telephone user part (TUP) message, a transaction capabilities application part (TCAP) message, and a session initiation protocol (SIP) message.
3. The method of claim 1 wherein receiving the signaling message at the screening module includes receiving the signaling message at a network element including the screening module wherein the network element includes a network element selected from a group consisting of a signal transfer point (STP), a signaling system number 7 (SS7) Internet protocol (IP) signaling gateway (SG) (SS7-IP SG), an SS7 gateway, a
SIP server, an IP multimedia subsystem (IMS) call state control function (CSCF) element, a short message gateway (SMG), a Softswitch (SS), and a media gateway controller (MGC).
4. The method of claim 1 comprising identifying, as part of the screening policy, a sequence in which the at least one application should process the signaling message.
5. The method of claim 1 comprising implementing, as part of the screening policy, on behalf of an end office in the form of a proxy service, a network feature selected from a group consisting of intelligent network (IN) and advanced IN (AIN) features.
6. The method of claim 1 wherein determining, from the screening policy, at least one application to perform message processing on the signaling message includes identifying at least one of a pre-paid services application, a number portability service application, a location portability service application, a usage measurements services application, a billing application, and an advanced intelligent routing services application to process the signaling message.
7. The method of claim 1 wherein modifying the at least one signaling message parameter includes placing a list of pointcodes (LOP) parameter into the signaling message.
8. The method of claim 7 wherein placing the LOP parameter into the signaling message includes creating at least one of an application point code field, an application ID field, a last application field, and a dirty bit field.
9. The method of claim 8 wherein creating the last application field associated with a last application includes providing an indication alerting the last application to remove the LOP parameter from the signaling message.
10. The method of claim 8 wherein creating the last application field associated with a last application includes providing an indication alerting the last application to replace the destination point code (DPC) field of a message transfer part (MTP) routing label within the signaling message with an original DPC parameter from the signaling message included as the last entry of the LOP parameter.
11. The method of claim 8 comprising modifying the dirty bit field at the at least one application to indicate that processing by the at least one application is complete.
12. The method of claim 1 wherein the at least one application comprises a plurality of applications and wherein the application routing information includes network addresses usable by the applications to route the signaling message between the applications and to a destination.
13. The method of claim 1 wherein the message processing performed on the signaling message includes triggerless message processing.
14. The method of claim 1 wherein the message processing performed on the signaling message includes triggered message processing.
15. A system for decentralized processing of signaling messages in a multi- application processing environment, the system comprising:
(a) a communication module for receiving a signaling message; and
(b) a screening module associated with the communication module for: (i) determining from a screening policy at least one of a plurality of applications to perform message processing on the signaling message;
(ii) modifying the signaling message to include application routing information to allow at least one of the plurality of applications to complete signaling message routing; and
(iii) forwarding the signaling message the at least one of the plurality of applications.
16. The system of claim 15 wherein the communication module is adapted to receive a signaling message selected from a group consisting of a triggerless signaling message, an ISDN user part (ISUP) message, a telephone user part (TUP) message, a transaction capabilities application part (TCAP) message, and a session initiation protocol (SIP) message.
17. The system of claim 15 wherein the screening module and the communication module are co-located with a network element selected from a group consisting of a signal transfer point (STP), a signaling system number 7 (SS7) Internet protocol (IP) signaling gateway (SG) (collectively SS7-IP SG), an SS7 gateway, a SIP server, an IP multimedia subsystem (IMS) call state control function (CSCF) element, a short message gateway (SMG), a Softswitch (SS), and a media gateway controller (MGC).
18. The system of claim 15 wherein the screening module is adapted to, based upon the screening policy, identify a sequence in which at least one of the plurality of applications should process the signaling message.
19. The system of claim 15 wherein the screening module is adapted to implement, as part of the screening policy, on behalf of an end office in the form of a proxy service, a network feature selected from a group consisting of intelligent network (IN) and advanced IN (AIN) features.
20. The system of claim 15 wherein the plurality of applications includes at least one of a pre-paid services application, a number portability service application, a location portability service application, a usage measurements services application, a billing application, and an advanced intelligent routing services application.
21. The system of claim 15 wherein, in modifying the signaling message, the screening module is adapted to place a list of pointcodes (LOP) parameter into the signaling message.
22. The system of claim 21 wherein the LOP parameter includes at least one of an application point code field, an application ID field, a last application field, and a dirty bit field.
23. The system of claim 22 wherein the last application field associated with a last application includes an indication alerting the last application to remove the LOP parameter from the signaling message.
24. The system of claim 22 wherein each of the plurality of applications are adapted to modify the dirty bit field to indicate that processing by each of the plurality of applications is complete.
25. The system of claim 15 wherein the at least one of a plurality of applications comprises a plurality of applications and wherein the application routing information includes network addresses usable by the applications and wherein the applications are adapted to use the network addresses to route the signaling message between the applications and to a destination.
26. The system of claim 15 wherein, in determining from the screening policy at least one of a plurality of applications to perform message processing on the signaling message, the screening module is adapted to determine from the screening policy at least one of the plurality of applications to perform triggerless message processing on the signaling message.
27. The system of claim 15 wherein, in determining from the screening policy at least one of a plurality of applications to perform message processing on the signaling message, the screening module is adapted to determine from the screening policy at least one of the plurality of applications to perform triggered message processing on the signaling . message.
28. A computer program product comprising computer-executable instructions embodied in a computer-readable medium for performing steps comprising:
(a) receiving a signaling message at a screening module; (b) determining from a screening policy at least one application to perform message processing on the signaling message; (c) modifying the signaling message to include application routing information to allow the at least one application to complete signaling message routing; (d) forwarding the signaling message to the at least one application; and
(e) at the least one application, routing the signaling message using the application routing information.
PCT/US2007/000492 2006-01-09 2007-01-09 Methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment WO2007081934A2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN2007800084876A CN101401086B (en) 2006-01-09 2007-01-09 Methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment
EP07709644.4A EP1974282B1 (en) 2006-01-09 2007-01-09 Methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment
BRPI0706370-9A BRPI0706370A2 (en) 2006-01-09 2007-01-09 computer program methods, systems, and products for decentralized signaling message processing in a multiple application processing environment

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US75729706P 2006-01-09 2006-01-09
US60/757,297 2006-01-09
US11/392,241 2006-03-29
US11/392,241 US8050253B2 (en) 2006-01-09 2006-03-29 Methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment

Publications (2)

Publication Number Publication Date
WO2007081934A2 true WO2007081934A2 (en) 2007-07-19
WO2007081934A3 WO2007081934A3 (en) 2007-12-13

Family

ID=38256982

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/000492 WO2007081934A2 (en) 2006-01-09 2007-01-09 Methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment

Country Status (5)

Country Link
US (1) US8050253B2 (en)
EP (1) EP1974282B1 (en)
CN (1) CN101401086B (en)
BR (1) BRPI0706370A2 (en)
WO (1) WO2007081934A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7856094B2 (en) 2005-03-21 2010-12-21 Tekelec Methods, systems, and computer program products for providing telecommunications services between a session initiation protocol (SIP) network and a signaling system 7 (SS7) network
US8059667B2 (en) 2007-01-31 2011-11-15 Tekelec Methods, systems, and computer program products for applying multiple communications services to a call
US9712341B2 (en) 2009-01-16 2017-07-18 Tekelec, Inc. Methods, systems, and computer readable media for providing E.164 number mapping (ENUM) translation at a bearer independent call control (BICC) and/or session intiation protocol (SIP) router

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7554974B2 (en) * 2004-03-09 2009-06-30 Tekelec Systems and methods of performing stateful signaling transactions in a distributed processing environment
US7760708B2 (en) 2005-07-08 2010-07-20 Tekelec Methods, systems, and computer program products for triggering SIP nodes to include SS7 routing information in response messages including information requested by SS7 nodes
WO2008130709A2 (en) * 2007-04-20 2008-10-30 Tekelec Systems, methods, and computer program products for providing service interaction and mediation in a communications network
US20090041205A1 (en) * 2007-08-10 2009-02-12 Tekelec Methods, systems, and computer program products for detecting and mitigating ping call events in a communications network
US9584959B2 (en) 2008-11-24 2017-02-28 Tekelec Global, Inc. Systems, methods, and computer readable media for location-sensitive called-party number translation in a telecommunications network
US9843650B2 (en) * 2009-09-03 2017-12-12 Avaya Inc. Intelligent module sequencing
EP3264686B1 (en) 2009-10-16 2018-12-12 Tekelec, Inc. Methods, systems, and computer readable media for providing diameter signaling router with integrated monitoring and/or firewall functionality
US8750126B2 (en) 2009-10-16 2014-06-10 Tekelec, Inc. Methods, systems, and computer readable media for multi-interface monitoring and correlation of diameter signaling information
EP2534794B1 (en) * 2010-02-12 2019-03-27 Tekelec, Inc. Methods, systems, and computer readable media for providing peer routing at a diameter node
CN102859944B (en) * 2010-02-12 2016-05-25 泰克莱克股份有限公司 For the method and apparatus of local application route is provided at DIAMETER Nodes
JP5732550B2 (en) 2011-03-03 2015-06-10 テケレック・インコーポレイテッドTekelec, Inc. Method, system, and computer-readable medium for enhancing Diameter signaling messages
US9344458B2 (en) * 2012-07-16 2016-05-17 eZuce, Inc. Providing unified communications services
US9367367B2 (en) * 2013-06-06 2016-06-14 Avaya Inc. Application router
US11108911B2 (en) * 2018-07-17 2021-08-31 Avaya Inc. System and method for flexible routing
CN109639722B (en) * 2019-01-07 2021-09-07 烽火通信科技股份有限公司 Method and system for realizing ISDN service access on SIP gateway

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003030429A2 (en) 2001-10-02 2003-04-10 Nokia Corporation System and method for providing at least one service obtained from a service network for a user in a packet switched communication network

Family Cites Families (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4191860A (en) * 1978-07-13 1980-03-04 Bell Telephone Laboratories, Incorporated Data base communication call processing method
EP0681405A1 (en) * 1994-05-06 1995-11-08 International Business Machines Corporation System for diverting signalling link traffic in a common channel signalling system
US5838683A (en) 1995-03-13 1998-11-17 Selsius Systems Inc. Distributed interactive multimedia system architecture
US5671225A (en) * 1995-09-01 1997-09-23 Digital Equipment Corporation Distributed interactive multimedia service system
US5826030A (en) * 1995-11-30 1998-10-20 Excel Switching Corporation Telecommunication switch having a universal API with a single call processing message including user-definable data and response message each having a generic format
CA2165856C (en) * 1995-12-21 2001-09-18 R. William Carkner Number portability with database query
US5852660A (en) * 1996-04-10 1998-12-22 Ericsson Inc. Network protocol conversion module within a telecommunications system
US5836683A (en) * 1997-03-11 1998-11-17 Institute For Advanced Engineering Mixing apparatus using acoustic resonance
SE512270C2 (en) * 1997-04-30 2000-02-21 Ericsson Telefon Ab L M Methods and systems for use in a telecommunications network
US6026233A (en) * 1997-05-27 2000-02-15 Microsoft Corporation Method and apparatus for presenting and selecting options to modify a programming language statement
US6002693A (en) * 1997-06-04 1999-12-14 Nortel Networks Corporation Method and system for routing messages in a telecommunication network using an expanded signalling link selector field
GB9711788D0 (en) * 1997-06-06 1997-08-06 Northern Telecom Ltd Method and interface for connecting communication traffic between narrowband and broadband networks
US7050456B1 (en) * 1998-12-04 2006-05-23 Tekelec Methods and systems for communicating signaling system 7 (SS7) user part messages among SS7 signaling points (SPs) and internet protocol (IP) nodes using signal transfer points (STPs)
US6779030B1 (en) * 1997-10-06 2004-08-17 Worldcom, Inc. Intelligent network
US6418461B1 (en) * 1997-10-06 2002-07-09 Mci Communications Corporation Intelligent call switching node in an intelligent distributed network architecture
US6182086B1 (en) * 1998-03-02 2001-01-30 Microsoft Corporation Client-server computer system with application recovery of server applications and client applications
US6160883A (en) * 1998-03-04 2000-12-12 At&T Corporation Telecommunications network system and method
US6145120A (en) * 1998-03-24 2000-11-07 Lockheed Martin Corporation Declaration programming language extension for procedural programming languages
US6167129A (en) * 1998-04-03 2000-12-26 Tekelec Method and apparatus for signal mediation in a common channel signaling network
US6249572B1 (en) * 1998-06-08 2001-06-19 Inet Technologies, Inc. Transaction control application part (TCAP) call detail record generation in a communications network
US6327267B1 (en) * 1998-12-21 2001-12-04 Ericssoninc Systems and methods for routing a message through a signaling network associated with a public switched telephone network (PSTN), including a method for performing global title routing on an internet protocol (IP) address
US20010053218A1 (en) * 1999-05-26 2001-12-20 Alex Leung Transaction bridging/forwarding in signaling system of telecommunications network
US6842447B1 (en) * 1999-06-14 2005-01-11 Mci, Inc. Internet protocol transport of PSTN-to-PSTN telephony services
US6701367B1 (en) * 1999-09-24 2004-03-02 Sun Microsystems, Inc. Mechanism for enabling customized session managers to interact with a network server
US6434155B1 (en) * 1999-12-22 2002-08-13 Alcatel Usa Sourcing, L.P. Weighted round robin engine used in scheduling the distribution of ATM cells
KR20010087959A (en) * 2000-03-09 2001-09-26 서평원 INAP Processing Method For TCAP Communication In SSP
US6625273B1 (en) * 2000-03-28 2003-09-23 Sevis Systems, Inc. System and method for a local number portability cache
US6731741B1 (en) * 2000-03-31 2004-05-04 Alcatel Signaling server for processing signaling information in a telecommunications network
US6959076B2 (en) * 2000-07-14 2005-10-25 Tekélec Methods and systems for providing triggerless intelligent network (IN) screening services based on call setup messages
JP2002049652A (en) * 2000-08-03 2002-02-15 Hiroshi Yasuda Digital circuit design method, its compiler and simulator
US20020048360A1 (en) * 2000-09-05 2002-04-25 Zambre Rajan A. System and methods for distributed telecommunication applications for the public switched telephone network and the public land mobile network
US6748585B2 (en) * 2000-11-29 2004-06-08 Microsoft Corporation Computer programming language pronouns
US6847639B2 (en) * 2000-12-05 2005-01-25 Lucent Technologies Inc. Managing feature interaction among a plurality of independent feature servers in telecommunications servers
EP1217816A1 (en) 2000-12-22 2002-06-26 Lucent Technologies Inc. Supporting legacy voice centric services in an IP multimedia network
US7058057B2 (en) * 2001-05-01 2006-06-06 Integrated Device Technology, Inc. Network switch port traffic manager having configurable packet and cell servicing
US20020178262A1 (en) * 2001-05-22 2002-11-28 David Bonnell System and method for dynamic load balancing
US6775373B2 (en) * 2001-06-14 2004-08-10 Ericsson Inc. System for and method of channel associated signaling backhaul in a routing system
WO2003017123A1 (en) * 2001-08-16 2003-02-27 Redline Networks, Inc. System and method for maintaining statefulness during client-server interactions
KR100407323B1 (en) 2001-09-19 2003-11-28 삼성전자주식회사 Method for duplicating call manager in private wireless network
US7286545B1 (en) * 2002-03-26 2007-10-23 Nortel Networks Limited Service broker
US6914973B2 (en) * 2002-06-25 2005-07-05 Tekelec Methods and systems for improving trunk utilization for calls to ported numbers
US8015303B2 (en) * 2002-08-02 2011-09-06 Astute Networks Inc. High data rate stateful protocol processing
US6785374B2 (en) * 2002-09-30 2004-08-31 Guanglu Wang Method and apparatus for providing transaction capabilities application part information in a session initiation protocol system
US6795546B2 (en) * 2002-11-14 2004-09-21 Tekelec Methods and systems for distributing signaling messages among multiple processors for stateful and/or sequenced processing of the messages on a per-sequence basis
EP1465440B1 (en) * 2003-04-03 2008-07-09 Hewlett-Packard Development Company, L.P. Method and apparatus for changeover of associations between signalling processes
US7245609B2 (en) * 2003-10-31 2007-07-17 Agilent Technologies, Inc. Apparatus and method for voice over IP traffic separation and factor determination
JP4155920B2 (en) * 2003-12-25 2008-09-24 株式会社日立コミュニケーションテクノロジー Media gateway and automatic call forwarding service system
US7554974B2 (en) * 2004-03-09 2009-06-30 Tekelec Systems and methods of performing stateful signaling transactions in a distributed processing environment
US7856094B2 (en) * 2005-03-21 2010-12-21 Tekelec Methods, systems, and computer program products for providing telecommunications services between a session initiation protocol (SIP) network and a signaling system 7 (SS7) network
US7792275B2 (en) * 2005-07-29 2010-09-07 Verizon Patent And Licensing Inc. Application service invocation
WO2008094648A1 (en) * 2007-01-31 2008-08-07 Tekelec Methods, systems, and computer program products for applying multiple communications services to a call
US8689334B2 (en) * 2007-02-28 2014-04-01 Alcatel Lucent Security protection for a customer programmable platform
WO2008130709A2 (en) 2007-04-20 2008-10-30 Tekelec Systems, methods, and computer program products for providing service interaction and mediation in a communications network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003030429A2 (en) 2001-10-02 2003-04-10 Nokia Corporation System and method for providing at least one service obtained from a service network for a user in a packet switched communication network

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7856094B2 (en) 2005-03-21 2010-12-21 Tekelec Methods, systems, and computer program products for providing telecommunications services between a session initiation protocol (SIP) network and a signaling system 7 (SS7) network
US8520828B2 (en) 2005-03-21 2013-08-27 Tekelec, Inc. Methods, systems, and computer program products for providing telecommunications services between a session initiation protocol (SIP) network and a signaling system 7 (SS7) network
US9001990B2 (en) 2005-03-21 2015-04-07 Tekelec, Inc. Methods, systems, and computer program products for providing telecommunications services between a session initiation protocol (SIP) network and a signaling system 7 (SS7) network
US8059667B2 (en) 2007-01-31 2011-11-15 Tekelec Methods, systems, and computer program products for applying multiple communications services to a call
US9712341B2 (en) 2009-01-16 2017-07-18 Tekelec, Inc. Methods, systems, and computer readable media for providing E.164 number mapping (ENUM) translation at a bearer independent call control (BICC) and/or session intiation protocol (SIP) router

Also Published As

Publication number Publication date
US8050253B2 (en) 2011-11-01
CN101401086A (en) 2009-04-01
EP1974282A2 (en) 2008-10-01
US20070168421A1 (en) 2007-07-19
CN101401086B (en) 2012-04-18
EP1974282A4 (en) 2012-05-30
WO2007081934A3 (en) 2007-12-13
BRPI0706370A2 (en) 2011-03-22
EP1974282B1 (en) 2018-10-17

Similar Documents

Publication Publication Date Title
US8050253B2 (en) Methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment
EP1356686B1 (en) Distributed signaling gateway
US9379965B2 (en) Organizing, managing, and selectively distributing routing information in a signaling message routing node
US7113581B2 (en) Methods and systems for providing dynamic routing key registration
US7313129B1 (en) Arrangement for sharing a single signaling point code between multiple hosts in an IP-based network
EP1738269B1 (en) Systems and methods of performing stateful signaling transactions in a distributed processing environment
US20070121908A1 (en) Methods, systems, and computer program products for providing address translation using subsequent address information
US8254553B2 (en) Systems, methods, and computer program products for number translation with local directory number support
US7136477B2 (en) Methods and systems for providing end office support in a signaling network
US6167129A (en) Method and apparatus for signal mediation in a common channel signaling network
US7127057B2 (en) Methods and systems for distributing application data among multiple processing modules in a telecommunications network element having a distributed internal processing architecture
US20070047539A1 (en) Methods, systems, and computer program products for preserving sequencing of signaling messages at a routing node
US20040032864A1 (en) Centralized service control for a telecommunication system
US7010114B2 (en) SS7 signaling server with integrated advanced signaling services
US7519051B2 (en) Methods and related apparatus for operating a gateway to act as a conduit for a structured transaction
US7043002B2 (en) Methods and systems for identifying, redirecting, and processing messages of different SS7 protocol variations
US20100309925A1 (en) Methods, systems, and computer program products for using signaling system 7 (ss7) subsystem numbers to route messages to session initiation protocol (sip) nodes
US20060098628A1 (en) Methods and apparatus for controlling signaling gateways
US8934380B2 (en) Methods, systems, and computer readable media for switching office trigger induction by an intermediate signaling node
WO2007087930A1 (en) Method and apparatus for transferring signaling connection control part messages

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 4068/CHENP/2008

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2007709644

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 200780008487.6

Country of ref document: CN

ENP Entry into the national phase

Ref document number: PI0706370

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20080709