WO2000060844A1 - Methods and systems for collecting and processing signaling system 7 (ss7) message signal units (msus) - Google Patents

Methods and systems for collecting and processing signaling system 7 (ss7) message signal units (msus) Download PDF

Info

Publication number
WO2000060844A1
WO2000060844A1 PCT/US2000/008123 US0008123W WO0060844A1 WO 2000060844 A1 WO2000060844 A1 WO 2000060844A1 US 0008123 W US0008123 W US 0008123W WO 0060844 A1 WO0060844 A1 WO 0060844A1
Authority
WO
WIPO (PCT)
Prior art keywords
msus
application
cdrs
msu
cdr
Prior art date
Application number
PCT/US2000/008123
Other languages
French (fr)
Inventor
Richard James Spangler
Steven Michael Freedman
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 AT00919712T priority Critical patent/ATE519329T1/en
Priority to AU40354/00A priority patent/AU4035400A/en
Priority to EP00919712A priority patent/EP1169845B1/en
Publication of WO2000060844A1 publication Critical patent/WO2000060844A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0029Provisions for intelligent networking
    • H04Q3/005Personal communication services, e.g. provisions for portability of subscriber numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4552Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4557Directories for hybrid networks, e.g. including telephone numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/169Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/12Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/1225Details of core network interconnection arrangements
    • H04M7/123Details of core network interconnection arrangements where the packet-switched network is an Internet Protocol Multimedia System-type network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0025Provisions for signalling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0029Provisions for intelligent networking
    • H04Q3/0045Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/4228Systems providing special services or facilities to subscribers in networks
    • H04M3/42297Systems providing special services or facilities to subscribers in networks with number portability

Definitions

  • the present invention relates to methods and systems for processing SS7 MSUs. More particularly, the present invention relates to methods and systems for creating call detail records (CDRs) from SS7 MSUs.
  • CDRs call detail records
  • SS7 is a common channel signaling protocol used by SS7 nodes to provide telecommunications services to end users. Messages that are transported between SS7 nodes to provide telecommunications services are referred to as signal units. There are three types of SS7 signal units: message signal units (MSUs); fill in signal units (FISUs); and link status signal units (LSSUs).
  • MSUs message signal units
  • FISUs fill in signal units
  • LSSUs link status signal units
  • FISUs are transmitted between SS7 nodes to constantly evaluate the status of SS7 links. FISUs do not carry any information relating to a call. LSSUs are sent between two signaling points to evaluate the status of a link between the two signaling points. Like FISUs, LSSUs do not contain any information relating to a call.
  • Message signal units carry routing information, user part information, and application part information relating to a call.
  • Many SS7 MSUs can be transmitted between SS7 nodes during a call. Accordingly, it is desirable to capture the SS7 MSUs and process the SS7 MSUs to generate call detail records.
  • a call detail record refers to any information extracted from one or more SS7 MSUs that can be used by an application to perform a specific function.
  • a call detail record for a call duration billing application may contain ISDN user part (ISUP) messages for a call.
  • a call detail record for an interconnect billing application may contain transaction capabilities application part (TCAP) query and response MSUs.
  • a call detail record for a calling card fraud detection application may contain both ISUP MSUs and TCAP query and response MSUs.
  • U.S. Patent No. 5,592,530 entitled “Telephone Dual Switch Monitors” discloses monitors that connect to a mated pair of SS7 signal transfer points (STPs). The monitors implement primary and secondary state machines to generate partial CDRs at each switch. Implementing primary and secondary state machines and generating partial CDRs at each switch increases the complexity of monitoring software. This complexity adds to the delay in CDR creation and prevents real time access to CDRs by downstream devices.
  • U.S. Patent No. 5,438,570 entitled “Service Observation Equipment for Signaling System Seven Telephone Network” describes another system for monitoring an SS7 network.
  • the system includes service observation equipment that connects to SS7 signaling links between an SS7 signaling point (SP) and an STP and to audio trunk connections between SS7 SPs.
  • the monitoring of trunk connections in addition to SS7 signaling links increases the complexity of the monitoring equipment. Such complexity is unnecessary in modern common channel signaling networks where control information required to establish a call is sent exclusively on a separate channel from the voice trunks.
  • the monitoring of SS7 MSUs at an SSP as described in the '570 Patent does not present the same correlation problems as monitoring MSUs at a mated pair of STPs because all messages sent to or from the SSP are guaranteed to pass through a single monitoring device.
  • Network Applications Platform provides a platform for diverse application programs to analyze SS7 signaling units.
  • SS7 signaling units are filtered according to categories and type based on filters configured by a master station.
  • the filters comprise linked lists of filtering criteria.
  • Applications running on a separate machine from the master station receive the filtered MSUs.
  • commands usable by the applications themselves to control filtering There is no disclosure of commands usable by the applications themselves to control filtering.
  • U.S. Patent No. 5,008,929 entitled "Billing System for Telephone Signaling Network” discloses a billing system for a telephone signaling network.
  • the billing system processes SS7 MSUs to produce usage data.
  • the usage data indicates the service recipients and the service providers for the MSUs.
  • the '929 Patent does not disclose an application interface for controlling the processing of MSUs or a method by which MSUs relating to a call are correlated.
  • the present invention provides a system for processing SS7 MSUs.
  • a monitoring device receives SS7 MSUs from SS7 signaling links.
  • a call detail record generator receives the SS7 MSUs and processes the SS7 MSUs to create call detail records from the MSUs.
  • An application interface kit (AIK) allows applications to control the flow and content of CDRs produced by the CDR generator.
  • Embodiments of the present invention will be described with reference to block diagrams and flow charts illustrating process components and steps for collecting and processing SS7 MSUs. It is understood that each of these components and steps can be implemented by computer-executable instructions embodied in a computer-readable medium. Alternatively, the process components and steps can be implemented entirely in hardware. In yet another alternative, the process components and steps can be implemented by a combination of hardware and software. Accordingly, it is an object of the present invention to provide novel methods and systems for collecting and processing SS7 MSUs.
  • FIG. 1 is a block diagram illustrating the system for processing SS7
  • FIG. 2 is a block diagram of a monitoring device configured to operate externally from an STP according to an embodiment of the present invention
  • FIG. 3 is a block diagram of an STP with internal MSU capturing and CDR generation according to an embodiment of the present invention
  • Figure 4 is a block diagram of a CDR generator program according to an embodiment of the present invention
  • Figure 5 is a block diagram illustrating an SS7 MSU
  • Figure 6 is a block diagram of a parser according to an embodiment of the present invention.
  • Figure 7 is a flow chart illustrating exemplary steps that may be performed by the correlator of the CDR generator program in correlating ISUP messages according to an embodiment of the present invention
  • Figure 8 is a flow chart illustrating exemplary steps that may be performed by a correlator of a CDR generator program in processing TCAP messages according to an embodiment of the present invention
  • FIG. 9 is block diagram of CDR manager program according to an embodiment of the present invention.
  • Figures 10(a)-10(c) are data structure diagrams illustrating exemplary commands usable by applications for controlling the flow of MSUs and CDRs according to an embodiment of the present invention
  • Figure 1 1 is a data structure diagram illustrating a data filter command usable by applications to control filtering of MSUs and CDRs according to an embodiment of the present invention.
  • Figure 12 is a data structure diagram illustrating a bulk delivery command usable by applications to request delivery of CDRs and MSUs in bulk.
  • the present invention includes a system for processing SS7 MSUs to generate call detail records.
  • Figure 1 illustrates a system for processing SS7 MSUs to generate call detail records according to an embodiment of the present invention.
  • SS7 SS7
  • signaling links 100 and 102 are transmitted over signaling links 100 and 102.
  • signaling links 100 and 102 provide SS7 MSUs to STPs 104 and
  • Signaling links 100 and 102 may comprise SS7 signaling links, such as access links, that connect STPs 104 and 106 to SSPs or SCPs, bridge links that connect STPs 104 and 106 to other mated STPs, diagonal links that connect STPs 104 and 106 to other mated pairs of STPs at a different hierarchical level, or extended links that connect STPs 104 and 106 to a remote STP.
  • signaling links 100 and 102 may comprise IP signaling links that carry SS7 MSUs over an IP network such as a TCP/IP network or a UDP/IP network. It is understood that each of signaling links 100 and 102 may represent one physical link or a plurality of physical links.
  • the present embodiment includes monitoring devices 108 and 110.
  • the monitoring devices include first interfaces 112 and 114 for copying SS7 MSUs from signaling links 100 and 102, CDR generator software 116 and 118 for processing MSUs received from the signaling links into CDRs, and second interfaces 120 and 122 for communicating CDRs and MSUs to downstream devices.
  • monitoring devices 108 and 110 are co- located with, but external to STPs 104 and 106. In an alternative embodiment, monitoring devices 108 and 110 may be integrated within STPs 104 and 106. Communication between monitoring devices 108 and 110 and STPs 104 and 106 will be discussed in more detail below.
  • CDR manager 124 communicates with monitoring devices 108 and 110 via wide area network (WAN) 126 to receive CDRs and MSUs from monitoring devices 108 and 110.
  • WAN wide area network
  • CDR manager 124 is a software entity that executes on a general purpose computer to receive CDRs and store CDRs in bulk storage 128.
  • CDR manager 124 receives CDRs generated by two monitoring devices 108 and 110.
  • the present invention is not limited to receiving CDRs from two monitoring devices connected to a mated pair of STPs.
  • CDR manager may receive CDRs from a single monitoring device or more than two monitoring devices.
  • CDR manager 124 may be located at a control site for a telecommunications service provider and receive CDRs from monitoring devices located at each STP owned by the service provider.
  • monitoring devices 108 and 110 and/or CDR manager 124 may include application interface kits 130 for receiving commands from applications and processing the commands to dynamically control the flow and content of CDRs and MSUs to the applications.
  • applications such as billing applications, billing verification applications, fraud detection applications, looping detection applications, mass call detection applications, etc.
  • applications can use a set of commands to instruct application interface kits 130 to start transmitting CDRs and/or MSUs, stop transmitting CDRs and/or MSUs, or change the content of CDRs and/or MSUs sent to applications.
  • An exemplary set of commands will be discussed in more detail below.
  • Monitoring Device Figure 2 illustrates an example of a monitoring device according to an embodiment of the present invention.
  • the monitoring device illustrated in Figure 2 is adapted to monitor signaling links at an STP at a location external to the STP using link probes to physically access the signaling links.
  • monitoring device 108 includes a main unit 108A and an external host 108B.
  • Main unit 108A includes hardware and software for copying MSUs from the signaling links.
  • main unit 108A may include link probes 200, 202, and 204 for physically accessing the signaling links.
  • Link probes 200, 202, and 204 are preferably high- resistance probes relative to the signaling links to avoid interfering with signals on the signaling links.
  • Link interface modules (LIMS) 206, 208, and 210 receive signals from link probes 200, 202, and 204 and convert the raw signals into frames.
  • the configuration of each LIM depends on the physical transfer medium of the link being monitored. For example, if signaling link is a T1 link, LIMs 206, 208, and 210 may be adapted to convert the T1 signal to frames, such as SS7 or Ethernet frames. Similarly, if a signaling link is an E1 link, LIMs 206, 208, and 210 may be configured to convert E1 signals to SS7 or Ethernet frames.
  • LIMs 206, 208, and 210 may be configured to convert the DS0 signals to SS7 or Ethernet frames.
  • Link interface controllers (LICs) 212, 214, and 216 receive the messages output from LIMs 206, 208, and 210 and perform SS7 layer 2 processing on the messages to ensure that duplicate copies of the same messages are not forwarded to downstream devices.
  • the outputs of LICs 212, 214, and 216 are single copies of SS7 messages.
  • Bus 218 interconnects link interface controllers 212, 214, and 216 and connects the link interface controllers to a control module 220.
  • Control module 220 contains the central processor and associated program memory for the monitoring device.
  • control module 220 Exemplary functions performed by control module 220 include communicating with external host 108B through I/O module 224, managing system errors, controlling remote diagnostic selection, and controlling system clocks. For purposes of explaining the present invention, the most important function performed by control module 220 is communicating SS7 MSUs to external host 108B through I/O module 224.
  • I/O module 224 includes an appropriate hardware interface for communicating with external host 108B.
  • I/O module 224 includes an Ethernet transceiver for communicating SS7 MSUs to external host 108B via an Ethernet interface.
  • I/O module 224 may be configured to communicate over a serial interface, such as an RS-232 interface.
  • a serial interface such as an RS-232 interface.
  • 108A is the main unit provided by the Message Generator/Traffic Simulator (MGTS), available from Tekelec, Inc. of Calabassas, California.
  • MGTS Message Generator/Traffic Simulator
  • the main unit of the MGTS includes the components illustrated in Figure 2, as well as additional components that are not essential in explaining the present invention.
  • External host 108B comprises a computing device, such as a personal computer or a workstation having sufficient processing capacity to process MSUs received from I/O module 224.
  • An exemplary hardware and software platform suitable for use as external host 108B is an Ultra 5 workstation running Solaris 2.0, available from Sun Microsystems, Inc. of Palo Alto, California.
  • An alternative hardware and software platform suitable for use as external host 108B is a personal computer, such as an IBM- compatible personal computer running a WINDOWS®-based operating system.
  • external host 108B includes CDR generator 116 for generating CDRs from MSUs received from I/O module 224 and application interface kit 118 for allowing applications to control the flow of CDRs and/or MSUs from CDR generator 116.
  • a monitoring device including a main unit 108A and an external host 108B.
  • the functions performed by external host 108B may be executed by a processor within control module 220 of main unit 108A.
  • a monitoring device according to the present embodiment includes configurations in which MSU copying and processing functions are integrated within a single physical device and configurations . in which MSU copying and processing functions are implemented within separate physical devices that communicate with each other.
  • the present invention is not limited to the external monitoring device illustrated in Figure 2.
  • the monitoring device may be integrated within an STP.
  • Figure 3 illustrates an integrated monitoring device according to an embodiment of the present invention.
  • monitoring and CDR generation functionality is integrated within STP 104.
  • STP 104 includes link interface modules (LIMs) 300, 302, and 304 for sending and receiving SS7 signal units over SS7 signal links 306 - 308.
  • LIMs 300, 302, and 304 each include hardware, such as a microprocessor and associated memory, for executing programs for interfacing with SS7 signaling links 306 - 308.
  • LIMs 300, 302, and 304 are capable of both sending and receiving MSUs.
  • MSU copy modules 310, 312, and 314 reside on LIMs 300, 302, and 304 for identifying and copying SS7 MSUs incoming on signaling links 306 - 308.
  • STP 104 may include data communications module (DCM) 315 for sending and receiving SS7 MSUs via TCP/IP network 316.
  • DCM 315 may include appropriate hardware, such as a microprocessor and associated memory for executing programs for interfacing with TCP/IP network 316.
  • DCM card functionality is found in commonly-assigned and copending U.S. Patent Application No.
  • An interprocessor message transfer bus 318 provides a communication link between LIMs 300, 302, and 304, DCM 315, and application control module (ACM) 319.
  • ACM 319 includes hardware and software for sending SS7 MSUs to an external host via a TCP/IP interface.
  • ACM 319 includes MSU receive module 320 for receiving copies of MSUs from IMT bus 318, CDR generator 116 for processing the MSUs into CDRs, and application interface kit 130 for controlling the flow of MSUs/CDRs to external applications.
  • MSU receive module 320 interfaces with bus 318 to receive copies of MSUs from bus 318.
  • CDR generator 116 and application interface kit 130 will be described in more detail below. The present invention is not limited to the embodiment illustrated in
  • STP 104 may include MSU copy modules 310, 312, 314, and 317 and MSU receive module 310.
  • application interface kit 130 and CDR generator 116 may be implemented on a host external to the STP that communicates with MSU receive module 310 through an appropriate interface, such as a TCP/IP interface.
  • a suitable STP that may be modified to include the CDR generation functionality illustrated in Figure 3 is the EAGLE® STP available from Tekelec, Inc. of Calabassas, California.
  • the EAGLE® STP includes DCM cards and LIM cards as illustrated in Figure 3, as well as additional functionality that is not relevant to a discussion of the present invention.
  • FIG 4 is a block diagram of an exemplary CDR generator program according to an embodiment of the present invention. Referring to Figure 4,
  • CDR generator 116 includes a receiver 400 for receiving MSUs from the CDR generator program monitoring the other side of a mated pair of STPs.
  • receiver 400 may be an application-layer interface that communicates with the other CDR generator program via TCP/IP or other appropriate protocol.
  • Collector 402 communicates with I/O module 224 illustrated in Figure 2 or with MSU receive module 320 illustrated in Figure 3 to receive copies of SS7 MSUs. Accordingly, collector 402 may include Ethernet hardware for communicating with I/O module 224 or bus interface circuitry for communicating with MSU receive module 320.
  • Parser 404 extracts parameters from the MSUs, such as the parameters required for CDR generation.
  • Correlator 406 is responsible for correlating MSU fragments from parser 404 and receiver 400 into complete CDRs.
  • Correlator 406 forwards message fragments to transfer block 408 if the MSU or MSU fragment is for a call that originated at the other CDR generator. For example, if a call originated at a monitoring device associated with a first STP of a mated pair of STPs, transfer block 408 forwards the MSU to the monitoring device associated with the other STP of a mated pair of STPs.
  • Transport block 410 may communicate with bulk storage and CDR manager 124 using any suitable protocol for transferring large amounts of data, such as file transfer protocol (FTP).
  • FTP file transfer protocol
  • Application interface kit 130 illustrated in Figure 1 may communicate with transport block 410 and/or bulk storage 430 to control the flow and content of CDRs to applications.
  • parser 404 parses MSUs received from collector
  • MSU 500 includes a plurality of fields used by SS7 nodes to perform call signaling and network management functions.
  • FCS frame check sequence
  • FCS field 502 is used by SS7 network management to determine if there are errors in the MSU.
  • Service information field 504 includes up to 272 octets of user data.
  • user data is information from an upper layer protocol, such as ISUP or TCAP. The user data also includes routing information used by lower level protocols to route the MSU to the proper destination.
  • Service information field 504 is divided into signaling information field 506, circuit information code (CIC) code field 508 and routing label 510.
  • Signaling information field 506 carries protocol-specific information. For example, if MSU 500 is an ISDN user part (ISUP) MSU, signaling information field 506 may carry an initial address message (IAM) and its associated parameters.
  • IAM initial address message
  • Circuit identification code field 508 identifies the circuit being set up or released by an ISUP message.
  • the circuit identification code may identify a voice trunk or any other transmission medium in the public switched telephone network.
  • Routing label 510 includes addresses for routing MSU 500.
  • routing label 510 includes originating point code (OPC) field 512, destination point code (DPC) field 514, and signaling link selection field 516.
  • Originating point code field 512 stores the point code of the SS7 node that originated the message.
  • Destination point code field 514 stores the point code of the SS7 node to which the message is to be routed.
  • Signaling link code field 516 stores a signaling link code that indicates the signaling link used to route the message.
  • the signaling information stored in service information field 504 may be useful in generating call detail records.
  • a call duration billing system may require information regarding call setup, call teardown, and voice trunk used. This information is contained in ISUP messages.
  • Information in CIC field 308 and routing label field 310, such as OPC and DPC may be useful to correlate messages. Accordingly, parser 404 illustrated in Figure 4 may extract one or more of these fields from MSU 500 generating a call detail record for a call duration billing application.
  • Service indicator octet (SIO) field 518 identifies the level 4 protocol of the message.
  • the SIO field may indicate that the level 4 protocol is ISUP, transaction capabilities application part (TCAP), or mobile application part (MAP). This information may also be useful in order to generate CDRs.
  • parser 404 illustrated in Figure 2 may also extract values from SIO field 518 of MSU 500.
  • the remaining fields in MSU 500 are used by lower level SS7 software for error detection and retransmission.
  • forward indicator bit field 520 and backwards indicator bit field 522 contain values utilized to control retransmission of messages.
  • Forward sequence number field 524 and backwards sequence number field 526 contain values for sequencing SS7 messages.
  • Link indicator field 528 stores a value representing the length of message signal unit 500. This field is useful to allow determination of the type of signal unit being received. For example, if the value in the length indicator field is greater than two, the signal unit is a message signaling unit.
  • Flag field 530 stores bits that indicate the start of an SS7 message. These remaining fields are generally not used in CDR generation but a discussion thereof is included herein for completeness.
  • parser 404 includes a parser engine 600, a user- configurable desired parameters database 602, and a parameter extraction instructions database 604.
  • Parser engine 600 is a program configured to read desired message parameters information from database 602 to determine the parameters to extract from incoming MSUs. Parser engine 600 then reads instructions for extracting the desired parameters form database 604 and follows the instructions to extract the desired parameters.
  • Desired parameters database 602 contains parameters that are desired to be extracted from incoming MSUs.
  • desired parameters database 602 comprises a user-editable text file that allows a user to set parameters to be extracted from MSUs, according to the needs of a particular application.
  • a call duration billing application may require CIC, OPC and DPC values.
  • the database user may configure database 602 to include these desired parameters. Accordingly, when parser engine 600 receives an MSU, parser engine 600 reads each desired parameter listed in database 602 and attempts to extract the parameter using instructions provided in database 604.
  • Database 604 contains instructions for extracting parameters from MSUs.
  • each entry in database 604 may include a first field 606 that corresponds to one of the desired parameters in database 602 and a second field 608 that contains instructions for extracting the desired parameter.
  • parameters for first field 606 may include CIC, OPC, and DPC.
  • Exemplary instructions for extracting the CIC from an MSU are as follows:
  • Instructions for extracting other parameters that are included in all MSUs, such as OPC and DPC, may simply involve going to the offset and reading the value.
  • Still other parameters, such as Called Party (CdPA) and Calling Party (CgPA) require extremely complex instructions.
  • CdPA Called Party
  • CgPA Calling Party
  • ISUP message type is equal to Initial Address Message (IAM), then goto offset for CdPA number pointer;
  • parser functionality easily modifiable.
  • a user need not know anything more than the parameter name to extract the parameter.
  • the parameter extraction instructions database removes the need for the user to remember how or where to locate a parameter.
  • the parser according to the present embodiment can be easily configured to extract MSU parameters for a variety of applications.
  • FIG. 7 illustrates exemplary steps that may be performed by correlator 406 illustrated in Figure 4 in correlating ISUP messages. The steps illustrated in Figure 7 assume a configuration similar to that illustrated in Figure 1 where a CDR generator program is associated with each STP of a mated pair of STPs.
  • correlator 406 receives MSU data from parser 404 or from the other CDR generator.
  • the MSU data includes fields extracted by parser 404 for a specific application.
  • correlator 406 determines whether the received MSU data relates to a new call. Determining whether the received MSU data relates to a new call may include examining the ISUP message type. For example, for ISUP messages, if the message is an IAM message, correlator 406 may determine that the message relates to a new call. In step ST2, if correlator 406 determines that the message relates to a new call, in step ST3 correlator 406 creates a new CDR for the call. Correlator 406 then returns to step ST1 to process the next message.
  • step ST2 if correlator 406 determines that the message does not relate to a new call, in step ST4 correlator 406 then determines whether the message relates to the call originating at the receiving CDR generator program. In order to make this determination, correlator 406 preferably compares one or more fields from the MSU data to a database of active CDRs at the receiving site. If correlator 406 determines that the MSU relates to a call originating at the receiving CDR generator program, in step ST5 correlator 406 locates the previously created CDR for the call and stores the MSU data in that record.
  • step ST4 if correlator 406 determines that the call did not originate at this CDR generator program, in step ST6 correlator 406 forwards the MSU data to the other CDR generator program.
  • the other CDR generator program receives the MSU data and performs the same steps illustrated in Figure 7 to store the MSU data in the same steps in the appropriate CDR.
  • Figure 7 illustrates exemplary correlation processing for ISUP messages
  • Figure 8 illustrates exemplary correlation processing for TCAP messages.
  • the steps illustrated in Figure 8 assume a configuration similar to that illustrated in Figure 1 where a CDR generator program is associated with each STP of a mated pair of STPs.
  • the steps illustrated in Figure 8 generate a CDR at one or the other monitoring devices for a TCAP query and response.
  • the steps illustrated in Figure 8 are designed to generate a correct CDR even when a race condition occurs due to detection of a TCAP response by a monitoring device before detection of a TCAP query by the other monitoring device.
  • the TCAP query may be sent through one STP of a mated pair of STPs and the response may be sent through the other STP of the mated pair.
  • monitoring devices are deployed at both STPs of the mated pair, for example as illustrated in Figure 1 , one monitoring device may receive a LIDB response before the other monitoring device receives the LIDB query.
  • the steps illustrated in Figure 8 demonstrate correlation of the query and response to generate a single correct CDR at one of the STPs, even when this condition occurs.
  • correlator 406 receives a TCAP message from the parser or from the other CDR generator program.
  • the TCAP message may be an entire TCAP MSU or any subset of the fields required for CDR generation.
  • correlator 406 determines whether the TCAP message is a query or a response. If the TCAP message is a response, in step ST3 correlator 406 determines whether the response was sent from the other CDR generator program. This condition occurs if the other CDR generator program received the response and did not have a CDR file query corresponding to the response.
  • step ST3 correlator 406 determines whether the response originated from the other CDR generator. This determination may include comparing fields in the response to fields in an active CDR database. If a CDR with a query corresponding to the response is present, in step ST6 correlator 406 stores the response in the CDR with the query and returns to step ST1 to process the next message. If a CDR with a query corresponding to the response is not present, in step ST7 correlator 406 opens a CDR for the response and returns to step ST1 to process the next message.
  • step ST3 if correlator 406 determines that the response is not from the other CDR generator, then the response was received from the parser at this CDR generator. Accordingly, in step ST7 correlator 406 checks for a CDR containing the query corresponding to the response at this CDR generator. In step ST8, if a CDR containing the query is present, correlator 406 proceeds to step ST9 and stores the response in the CDR with the query. Correlator 406 then returns to step ST1 to process the next message. In step ST7, if correlator 406 determines that a CDR with a query corresponding to the response is not present, in step ST9 correlator 406 forwards the response to the other CDR generator. Correlator 406 then returns to step ST1 to process the next message.
  • step ST2 if correlator 406 determines that the TCAP message received from the parser is a query, in steps ST10 and ST11 correlator 406 checks for a CDR containing a response forwarded from the other CDR generator program. In step ST11 , if correlator 406 determines that a response CDR is present, in step ST12 correlator 406 stores the query in the CDR with the response. Correlator 406 then returns to step ST1 to process the next message. In step ST11 , if correlator 406 determines that a response CDR is not present, in step ST13 correlator 406 opens a new CDR for the query and stores the query in that CDR. Correlator 406 then returns to step ST1 to process the next message.
  • the steps performed by correlator 406 in Figure 8 avoid race conditions. For example, if a response is received at one CDR generator before the other CDR generator receives a query, the response is forwarded to the other CDR generator. The other CDR generator, in response to receiving the response forwarded from the first CDR generator, opens a new CDR containing the response. When the query arrives at the CDR generator that received the forwarded response, the CDR generator stores the query in the CDR containing the forwarded response. In this manner, proper CDRs are created for TCAP transactions, such as LIDB transactions, even when race conditions occur.
  • FIG. 9 is a block diagram of CDR manager 124 illustrated in Figure 2.
  • CDR manager includes a collector 900 for receiving CDRs from transport block 410 illustrated in Figure 4. Communication with transport block 410 may occur using any suitable protocol for transferring data, such as FTP.
  • Transport block 902 receives CDRs from collector 900 and transports the CDRs to bulk storage 128 via a suitable network communications protocol, such as TCP/IP or UDP/IP.
  • CDR manager 132 includes an application interface kit 130 that allows third party applications to access CDRs and/or MSUs stored in bulk storage 128.
  • Application interface kit 130 includes a set of application programming interfaces (APIs) that allows applications to access CDRs and/or MSUs in both real time and in bulk.
  • APIs application programming interfaces
  • real time it is meant that application interface kit 130 allows an application to change the flow and/or content of CDRs and/or MSUs received by the application in a short time period, e.g., on the order of milliseconds or seconds.
  • Application interface kit 130 includes two separate halves. The first half is a server.
  • the application interface kit server can be part of the CDR manager program and handles all commands and requests from the second half of the application interface kit, the AIK client.
  • the application interface kit server can be part of the CDR generator program as illustrated in Figure 4.
  • the application interface kit client is linked into a user application and provides commands that the user application can send to the application interface kit server.
  • the application interface kit server and the application interface kit client can communicate with each other via a TCP/IP connection or other appropriate protocol.
  • FIG 10(a) illustrates an exemplary CDR generator command data structure provided by application interface kit 130.
  • the CDR generator command includes a type field 1000, a command identifier field 1002, a transaction identifier field 1004, and a data length field 1006.
  • each field is encoded as one byte in the command data structure.
  • the entire command is encapsulated in a network packet, such as a TCP segment or a UDP datagram, and transmitted between the application and the CDR manager or CDR generator.
  • Figure 10(b) illustrates exemplary values for command type field 1000 illustrated in Figure 10(a).
  • the first column 1010 includes the bit pattern that encodes each command type.
  • the second column 1012 includes a description of each command type.
  • the bit pattern 00000001 identifies a GET command.
  • the GET command is used to obtain attributes from the CDR manager or CDR generator and statistical information regarding generated CDRs. Examples of attributes that may be obtained are AIK Version, which is associated with compatibility checking, and Active Links, which returns a listing of links with currently active CDR generation.
  • the bit pattern 00000010 identifies the SET command.
  • the SET command is used to control behavior of the CDR generator or CDR manager.
  • the SET command may be used to stop and start the flow of CDRs or MSUs in real time.
  • the bit pattern 0000100 identifies the RESPONSE command.
  • the RESPONSE command is a response to the CDR generator command.
  • the byte pattern 00001000 identifies the TRAP message.
  • the TRAP message is an asynchronous message sent from the CDR generator program or CDR manager program to an application to provide real time information to the application about ongoing processes.
  • a TRAP CDR message contains information associated with one or more CDR records
  • a TRAP Error message contains information associated with error conditions in the system. .
  • Figure 10(c) illustrates exemplary identifiers that may be transmitted in identifier field 1002 of a CDR generation message.
  • the first column 1014 includes a bit pattern for each of the supported identifiers.
  • the second column 1016 includes a brief description of each identifier function.
  • the bit pattern 00000000 instructs the application interface kit server to stop sending CDRs in real time.
  • the bit 00000001 instructs the application interface kit server to start sending CDRs in real time without filtering.
  • filtering refers to the filtering of MSUs or CDRs based on parameters in the MSUs or CDRs.
  • FIG. 11 illustrates an exemplary data structure for a filter message.
  • filter message 1018 includes a parameter name length field 1020, a parameter name field 1022, a value length field 1024, and a value field 1026.
  • Parameter name length field 1020 stores a value that represents the length of the parameter in an appropriate unit, such as bits or bytes.
  • Parameter name field 1022 includes a name for the parameter that is recognizable by the application interface kit server. Exemplary parameter names that may be used as filter criteria includes OPC, DPC, SIO, CIC, etc.
  • Value length field 1024 includes the length of value field 1026, in any appropriate units such as bytes or bits.
  • Value field 1026 includes the value of the parameter specified in parameter name field 1022. For example, if the parameter specified in parameter name field 1022 is OPC, the value specified in value field 1026 may be 2-0-0. In another example, parameter name field 1022 may specify an IP address. In this case, an exemplary value that may be stored in value field 1026 is 255.255.255.255. Thus, by allowing applications to send filtering messages and control filtering in real time, the application interface kit according to embodiments of the present invention allows real time control of MSUs and CDRs received by an application.
  • bit pattern 0000010 instructs the application interface kit server to start sending intermediate CDRs in real time without filtering.
  • intermediate CDRs refer to CDRs that may not be complete.
  • an intermediate CDR may be some but not all of the messages used to perform call setup or call teardown.
  • Bit pattern 1000100 instructs application interface kit server to start sending intermediate CDRs in real time with filtering. As stated above, such a message is preferably followed by a filtering message, which instructs application interface kit server of the filter criteria.
  • Bit pattern 00000100 instructs the application interface kit server to stop sending MSUs in real time.
  • Bit pattern 00001000 instr ⁇ cts application interface kit server to start sending MSUs in real time without filtering.
  • Bit pattern 10001000 instructs application interface kit server to start sending MSUs in real time with filtering.
  • FIG. 12 illustrates an exemplary data structure for a CDR/MSU bulk data request message.
  • bulk data request message 1028 includes start time field 1030, stop time field 1032, requester IP address field 1034, location length field 1036, and location field 1038.
  • Start and stop time fields 1030 and 1032 specify the range of time for which CDRs are requested. For example, it may be desirable to request all CDRs generated from 8:00 am to 5:00 pm during a given day.
  • Requestor IP address field 1034 stores the IP address of the application requesting CDRs.
  • Location length field 1036 specifies the length of the storage field location.
  • location field 1038 specifies the location on the application interface kit server for storing CDRs.
  • the interface kit server In response to receiving bulk data request message 1028, application the interface kit server extracts the appropriate CDRs from bulk storage and initiates an appropriate bulk file transfer protocol such as FTP, to communicate the CDRs to the application interface kit client.
  • an appropriate bulk file transfer protocol such as FTP
  • bit pattern 001000000 instructs the application interface kit server to retrieve MSUs in bulk.
  • the operation of this command is similar to the command for retrieving CDRs in bulk. Hence, a description thereof is not repeated herein.
  • Bit pattern 01000000 instructs the receiving entity to send user configuration information to the requester. Exemplary user configuration information that may be sent in response to this command includes the monitoring software version of the receiver.
  • the application interface kit provides a mechanism for controlling the flow and content of CDRs and/or MSUs in real time.
  • This controllability by applications facilitates application design without requiring modification to the CDR generation or management software.
  • embodiments of the present invention facilitate development of applications that utilize CDRs or MSUs. Examples of such applications include call duration billing, call duration billing verification, interconnect billing verification, looping detection, mass call detection, fraud detection, such as calling card fraud detection, etc.
  • CDR Examples Both call duration billing and fraud detection applications may require CDRs containing a record of ISUP messages exchanged during a call.
  • An example of ISUP CDR content is as follows: Initial address message (1AM)
  • TCAP CDR content is as follows:
  • TXID Transaction ID
  • the present invention is not limited to generating the CDRs listed above. As stated earlier, the present invention is adaptable to generate CDRs containing any content from an SS7 MSU. Such content is modifiable simply by altering desired parameters in the parameters database accessed by the parser or by sending filtering commands to the application interface kit server.

Abstract

A system for collecting and processing SS7 message signaling units (MSUs) includes a network interface for copying MSUs from an SS7 signaling link or a TCP/IP signaling link (100, 102). A call detail record generator (116, 118) communicates with the link interface (112, 114) to receive the copied MSUs and parse the MSUs to extract desired parameters from the MSUs. An application interface kit (130) received commands from an application to control the flow of MSU parameters to the application in real time.

Description

Description
METHODS AND SYSTEMS FOR COLLECTING AND PROCESSING
SIGNALING SYSTEM 7 (SS7) MESSAGE SIGNAL UNITS (MSUs)
Priority Application Information This application claims the benefit of United States Provisional Patent Application No. 60/127,889 filed April 5, 1999, the disclosure of which is incorporated herein by reference in its entirety.
Technical Field The present invention relates to methods and systems for processing SS7 MSUs. More particularly, the present invention relates to methods and systems for creating call detail records (CDRs) from SS7 MSUs.
Field of the Invention SS7 is a common channel signaling protocol used by SS7 nodes to provide telecommunications services to end users. Messages that are transported between SS7 nodes to provide telecommunications services are referred to as signal units. There are three types of SS7 signal units: message signal units (MSUs); fill in signal units (FISUs); and link status signal units (LSSUs). FISUs are transmitted between SS7 nodes to constantly evaluate the status of SS7 links. FISUs do not carry any information relating to a call. LSSUs are sent between two signaling points to evaluate the status of a link between the two signaling points. Like FISUs, LSSUs do not contain any information relating to a call. Message signal units carry routing information, user part information, and application part information relating to a call. Many SS7 MSUs can be transmitted between SS7 nodes during a call. Accordingly, it is desirable to capture the SS7 MSUs and process the SS7 MSUs to generate call detail records. As used herein, a call detail record refers to any information extracted from one or more SS7 MSUs that can be used by an application to perform a specific function. For example, a call detail record for a call duration billing application may contain ISDN user part (ISUP) messages for a call. A call detail record for an interconnect billing application may contain transaction capabilities application part (TCAP) query and response MSUs. A call detail record for a calling card fraud detection application may contain both ISUP MSUs and TCAP query and response MSUs.
There are a variety of known systems for capturing and processing SS7 MSUs. For example, U.S. Patent No. 5,592,530 entitled "Telephone Dual Switch Monitors" discloses monitors that connect to a mated pair of SS7 signal transfer points (STPs). The monitors implement primary and secondary state machines to generate partial CDRs at each switch. Implementing primary and secondary state machines and generating partial CDRs at each switch increases the complexity of monitoring software. This complexity adds to the delay in CDR creation and prevents real time access to CDRs by downstream devices. U.S. Patent No. 5,438,570 entitled "Service Observation Equipment for Signaling System Seven Telephone Network" describes another system for monitoring an SS7 network. The system includes service observation equipment that connects to SS7 signaling links between an SS7 signaling point (SP) and an STP and to audio trunk connections between SS7 SPs. The monitoring of trunk connections in addition to SS7 signaling links increases the complexity of the monitoring equipment. Such complexity is unnecessary in modern common channel signaling networks where control information required to establish a call is sent exclusively on a separate channel from the voice trunks. In addition, the monitoring of SS7 MSUs at an SSP as described in the '570 Patent does not present the same correlation problems as monitoring MSUs at a mated pair of STPs because all messages sent to or from the SSP are guaranteed to pass through a single monitoring device. U.S. Patent No. 5,579,371 entitled "Common Channel Signaling
Network Applications Platform" provides a platform for diverse application programs to analyze SS7 signaling units. SS7 signaling units are filtered according to categories and type based on filters configured by a master station. The filters comprise linked lists of filtering criteria. Applications running on a separate machine from the master station receive the filtered MSUs. There is no disclosure of commands usable by the applications themselves to control filtering. Thus, while the '371 Patent discloses a common channel signaling network applications platform, control of the filtering and flow of the MSUs to an application must be manually performed by the operator of the master station. U.S. Patent No. 5,008,929 entitled "Billing System for Telephone Signaling Network" discloses a billing system for a telephone signaling network. The billing system processes SS7 MSUs to produce usage data. The usage data indicates the service recipients and the service providers for the MSUs. The '929 Patent does not disclose an application interface for controlling the processing of MSUs or a method by which MSUs relating to a call are correlated.
In light of these difficulties associated with the prior art, there exists a long-felt need for novel methods and systems for processing SS7 MSUs.
Summary of the Invention According to one aspect, the present invention provides a system for processing SS7 MSUs. In the system, a monitoring device receives SS7 MSUs from SS7 signaling links. A call detail record generator receives the SS7 MSUs and processes the SS7 MSUs to create call detail records from the MSUs. An application interface kit (AIK) allows applications to control the flow and content of CDRs produced by the CDR generator.
Embodiments of the present invention will be described with reference to block diagrams and flow charts illustrating process components and steps for collecting and processing SS7 MSUs. It is understood that each of these components and steps can be implemented by computer-executable instructions embodied in a computer-readable medium. Alternatively, the process components and steps can be implemented entirely in hardware. In yet another alternative, the process components and steps can be implemented by a combination of hardware and software. Accordingly, it is an object of the present invention to provide novel methods and systems for collecting and processing SS7 MSUs.
Some of the objects of the invention having been stated hereinabove, other objects will be evident as the description proceeds, when taken in connection with the accompanying drawings as best described hereinbelow.
Brief Description of the Drawings The present invention will now be explained with reference to the accompanying drawings, of which: Figure 1 is a block diagram illustrating the system for processing SS7
MSUs to generate call detail records according to an embodiment of the present invention;
Figure 2 is a block diagram of a monitoring device configured to operate externally from an STP according to an embodiment of the present invention;
Figure 3 is a block diagram of an STP with internal MSU capturing and CDR generation according to an embodiment of the present invention;
Figure 4 is a block diagram of a CDR generator program according to an embodiment of the present invention; Figure 5 is a block diagram illustrating an SS7 MSU;
Figure 6 is a block diagram of a parser according to an embodiment of the present invention;
Figure 7 is a flow chart illustrating exemplary steps that may be performed by the correlator of the CDR generator program in correlating ISUP messages according to an embodiment of the present invention; Figure 8 is a flow chart illustrating exemplary steps that may be performed by a correlator of a CDR generator program in processing TCAP messages according to an embodiment of the present invention;
Figure 9 is block diagram of CDR manager program according to an embodiment of the present invention;
Figures 10(a)-10(c) are data structure diagrams illustrating exemplary commands usable by applications for controlling the flow of MSUs and CDRs according to an embodiment of the present invention;
Figure 1 1 is a data structure diagram illustrating a data filter command usable by applications to control filtering of MSUs and CDRs according to an embodiment of the present invention; and
Figure 12 is a data structure diagram illustrating a bulk delivery command usable by applications to request delivery of CDRs and MSUs in bulk.
Detailed Description of the Invention
According to one embodiment, the present invention includes a system for processing SS7 MSUs to generate call detail records. Figure 1 illustrates a system for processing SS7 MSUs to generate call detail records according to an embodiment of the present invention. In Figure 1 , SS7
MSUs are transmitted over signaling links 100 and 102. In the illustrated example, signaling links 100 and 102 provide SS7 MSUs to STPs 104 and
106. Signaling links 100 and 102 may comprise SS7 signaling links, such as access links, that connect STPs 104 and 106 to SSPs or SCPs, bridge links that connect STPs 104 and 106 to other mated STPs, diagonal links that connect STPs 104 and 106 to other mated pairs of STPs at a different hierarchical level, or extended links that connect STPs 104 and 106 to a remote STP. Alternatively, signaling links 100 and 102 may comprise IP signaling links that carry SS7 MSUs over an IP network such as a TCP/IP network or a UDP/IP network. It is understood that each of signaling links 100 and 102 may represent one physical link or a plurality of physical links.
In order to monitor MSUs on signaling links 100 and 102, the present embodiment includes monitoring devices 108 and 110. The monitoring devices include first interfaces 112 and 114 for copying SS7 MSUs from signaling links 100 and 102, CDR generator software 116 and 118 for processing MSUs received from the signaling links into CDRs, and second interfaces 120 and 122 for communicating CDRs and MSUs to downstream devices.
In the illustrated embodiment, monitoring devices 108 and 110 are co- located with, but external to STPs 104 and 106. In an alternative embodiment, monitoring devices 108 and 110 may be integrated within STPs 104 and 106. Communication between monitoring devices 108 and 110 and STPs 104 and 106 will be discussed in more detail below.
CDR manager 124 communicates with monitoring devices 108 and 110 via wide area network (WAN) 126 to receive CDRs and MSUs from monitoring devices 108 and 110. CDR manager 124 is a software entity that executes on a general purpose computer to receive CDRs and store CDRs in bulk storage 128. In the illustrated embodiment, CDR manager 124 receives CDRs generated by two monitoring devices 108 and 110. However, the present invention is not limited to receiving CDRs from two monitoring devices connected to a mated pair of STPs. In an alternative embodiment, CDR manager may receive CDRs from a single monitoring device or more than two monitoring devices. For example, CDR manager 124 may be located at a control site for a telecommunications service provider and receive CDRs from monitoring devices located at each STP owned by the service provider.
According to an important aspect of the invention, monitoring devices 108 and 110 and/or CDR manager 124 may include application interface kits 130 for receiving commands from applications and processing the commands to dynamically control the flow and content of CDRs and MSUs to the applications. For example, applications, such as billing applications, billing verification applications, fraud detection applications, looping detection applications, mass call detection applications, etc., can use a set of commands to instruct application interface kits 130 to start transmitting CDRs and/or MSUs, stop transmitting CDRs and/or MSUs, or change the content of CDRs and/or MSUs sent to applications. An exemplary set of commands will be discussed in more detail below.
Monitoring Device Figure 2 illustrates an example of a monitoring device according to an embodiment of the present invention. The monitoring device illustrated in Figure 2 is adapted to monitor signaling links at an STP at a location external to the STP using link probes to physically access the signaling links. In the illustrated embodiment, monitoring device 108 includes a main unit 108A and an external host 108B. Main unit 108A includes hardware and software for copying MSUs from the signaling links. For example, main unit 108A may include link probes 200, 202, and 204 for physically accessing the signaling links. Link probes 200, 202, and 204 are preferably high- resistance probes relative to the signaling links to avoid interfering with signals on the signaling links. Link interface modules (LIMS) 206, 208, and 210 receive signals from link probes 200, 202, and 204 and convert the raw signals into frames. The configuration of each LIM depends on the physical transfer medium of the link being monitored. For example, if signaling link is a T1 link, LIMs 206, 208, and 210 may be adapted to convert the T1 signal to frames, such as SS7 or Ethernet frames. Similarly, if a signaling link is an E1 link, LIMs 206, 208, and 210 may be configured to convert E1 signals to SS7 or Ethernet frames. If a signaling link is a DS0 link, LIMs 206, 208, and 210 may be configured to convert the DS0 signals to SS7 or Ethernet frames. Link interface controllers (LICs) 212, 214, and 216 receive the messages output from LIMs 206, 208, and 210 and perform SS7 layer 2 processing on the messages to ensure that duplicate copies of the same messages are not forwarded to downstream devices. Thus, the outputs of LICs 212, 214, and 216 are single copies of SS7 messages. Bus 218 interconnects link interface controllers 212, 214, and 216 and connects the link interface controllers to a control module 220. Control module 220 contains the central processor and associated program memory for the monitoring device. Exemplary functions performed by control module 220 include communicating with external host 108B through I/O module 224, managing system errors, controlling remote diagnostic selection, and controlling system clocks. For purposes of explaining the present invention, the most important function performed by control module 220 is communicating SS7 MSUs to external host 108B through I/O module 224.
I/O module 224 includes an appropriate hardware interface for communicating with external host 108B. In a preferred embodiment, I/O module 224 includes an Ethernet transceiver for communicating SS7 MSUs to external host 108B via an Ethernet interface. In an alternative embodiment, I/O module 224 may be configured to communicate over a serial interface, such as an RS-232 interface. An exemplary commercially available device usable as main unit
108A is the main unit provided by the Message Generator/Traffic Simulator (MGTS), available from Tekelec, Inc. of Calabassas, California. The main unit of the MGTS includes the components illustrated in Figure 2, as well as additional components that are not essential in explaining the present invention.
External host 108B comprises a computing device, such as a personal computer or a workstation having sufficient processing capacity to process MSUs received from I/O module 224. An exemplary hardware and software platform suitable for use as external host 108B is an Ultra 5 workstation running Solaris 2.0, available from Sun Microsystems, Inc. of Palo Alto, California. An alternative hardware and software platform suitable for use as external host 108B is a personal computer, such as an IBM- compatible personal computer running a WINDOWS®-based operating system. In the illustrated embodiment, external host 108B includes CDR generator 116 for generating CDRs from MSUs received from I/O module 224 and application interface kit 118 for allowing applications to control the flow of CDRs and/or MSUs from CDR generator 116.
The present invention is not intended to be limited to a monitoring device including a main unit 108A and an external host 108B. For example, in an alternative embodiment, the functions performed by external host 108B may be executed by a processor within control module 220 of main unit 108A. Thus, a monitoring device according to the present embodiment includes configurations in which MSU copying and processing functions are integrated within a single physical device and configurations . in which MSU copying and processing functions are implemented within separate physical devices that communicate with each other.
The present invention is not limited to the external monitoring device illustrated in Figure 2. For example, in an alternative embodiment, the monitoring device may be integrated within an STP. Figure 3 illustrates an integrated monitoring device according to an embodiment of the present invention. In the illustrated embodiment, monitoring and CDR generation functionality is integrated within STP 104. STP 104 includes link interface modules (LIMs) 300, 302, and 304 for sending and receiving SS7 signal units over SS7 signal links 306 - 308. LIMs 300, 302, and 304 each include hardware, such as a microprocessor and associated memory, for executing programs for interfacing with SS7 signaling links 306 - 308. Unlike LIMs 206, 208, and 210 in the external monitoring device illustrated in Figure 2, which are capable of only receiving MSUs from SS7 signaling links, LIMs 300, 302, and 304 are capable of both sending and receiving MSUs. MSU copy modules 310, 312, and 314 reside on LIMs 300, 302, and 304 for identifying and copying SS7 MSUs incoming on signaling links 306 - 308.
The present invention is not limited to copying MSUs incoming to an STP on SS7 signaling links. For example, in addition to copying MSUs incoming on SS7 signaling links, STP 104 may include data communications module (DCM) 315 for sending and receiving SS7 MSUs via TCP/IP network 316. DCM 315 may include appropriate hardware, such as a microprocessor and associated memory for executing programs for interfacing with TCP/IP network 316. A detailed description of DCM card functionality is found in commonly-assigned and copending U.S. Patent Application No. 09/443,712 entitled "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)", the disclosure of which is incorporated herein by reference in its entirety. In addition, although not illustrated in Figure 2, it is understood that DCM functionality for copying MSUs received over a TCP/IP signaling link may be included in a monitoring device that resides external to an STP.
An interprocessor message transfer bus 318 provides a communication link between LIMs 300, 302, and 304, DCM 315, and application control module (ACM) 319. ACM 319 includes hardware and software for sending SS7 MSUs to an external host via a TCP/IP interface. In the illustrated embodiment, ACM 319 includes MSU receive module 320 for receiving copies of MSUs from IMT bus 318, CDR generator 116 for processing the MSUs into CDRs, and application interface kit 130 for controlling the flow of MSUs/CDRs to external applications. MSU receive module 320 interfaces with bus 318 to receive copies of MSUs from bus 318. CDR generator 116 and application interface kit 130 will be described in more detail below. The present invention is not limited to the embodiment illustrated in
Figure 3 in which the MSU copying functionality and the CDR generation functionality resides within STP 104. For example, in an alternative embodiment, the MSU copying functionality may be internal to the STP and the CDR generation functionality may be external to the STP. Thus, in an alternative embodiment, STP 104 may include MSU copy modules 310, 312, 314, and 317 and MSU receive module 310. However, application interface kit 130 and CDR generator 116 may be implemented on a host external to the STP that communicates with MSU receive module 310 through an appropriate interface, such as a TCP/IP interface. A suitable STP that may be modified to include the CDR generation functionality illustrated in Figure 3 is the EAGLE® STP available from Tekelec, Inc. of Calabassas, California. The EAGLE® STP includes DCM cards and LIM cards as illustrated in Figure 3, as well as additional functionality that is not relevant to a discussion of the present invention.
CDR Generator
Figure 4 is a block diagram of an exemplary CDR generator program according to an embodiment of the present invention. Referring to Figure 4,
CDR generator 116 includes a receiver 400 for receiving MSUs from the CDR generator program monitoring the other side of a mated pair of STPs. For example, receiver 400 may be an application-layer interface that communicates with the other CDR generator program via TCP/IP or other appropriate protocol. Collector 402 communicates with I/O module 224 illustrated in Figure 2 or with MSU receive module 320 illustrated in Figure 3 to receive copies of SS7 MSUs. Accordingly, collector 402 may include Ethernet hardware for communicating with I/O module 224 or bus interface circuitry for communicating with MSU receive module 320.
Parser 404 extracts parameters from the MSUs, such as the parameters required for CDR generation. Correlator 406 is responsible for correlating MSU fragments from parser 404 and receiver 400 into complete CDRs. Correlator 406 forwards message fragments to transfer block 408 if the MSU or MSU fragment is for a call that originated at the other CDR generator. For example, if a call originated at a monitoring device associated with a first STP of a mated pair of STPs, transfer block 408 forwards the MSU to the monitoring device associated with the other STP of a mated pair of STPs.
This forwarding of messages between monitoring devices allows only one CDR generator to generate a CDR for a call. This system can be contrasted with the system described in U.S. Patent No. 5,592,530 referenced above where each monitor connected to an STP generates a partial CDR. According to the present embodiment, each MSU received by a CDR generator program that does not belong to a call originating at the receiving CDR generator program is forwarded to the other CDR generator program. This increases the speed and decreases the complexity of CDR generation over the system described in the '530 Patent discussed above. Transport block 410 sends CDRs received from correlator 408 to bulk storage 430 and to CDR manager 124 illustrated in Figure 1. Transport block 410 may communicate with bulk storage and CDR manager 124 using any suitable protocol for transferring large amounts of data, such as file transfer protocol (FTP). Application interface kit 130 illustrated in Figure 1 may communicate with transport block 410 and/or bulk storage 430 to control the flow and content of CDRs to applications.
Parser As stated above, parser 404 parses MSUs received from collector
402 to extract parameters required for CDR generation. Figure 5 illustrates exemplary parameters that may be included in an SS7 MSU. In Figure 5, MSU 500 includes a plurality of fields used by SS7 nodes to perform call signaling and network management functions. The most significant field in MSU 500 is frame check sequence (FCS) field 502. FCS field 502 is used by SS7 network management to determine if there are errors in the MSU. The next field in MSU 500 is service information field 504. Service information field 504 includes up to 272 octets of user data. In SS7, user data is information from an upper layer protocol, such as ISUP or TCAP. The user data also includes routing information used by lower level protocols to route the MSU to the proper destination.
Service information field 504 is divided into signaling information field 506, circuit information code (CIC) code field 508 and routing label 510. Signaling information field 506 carries protocol-specific information. For example, if MSU 500 is an ISDN user part (ISUP) MSU, signaling information field 506 may carry an initial address message (IAM) and its associated parameters.
Circuit identification code field 508 identifies the circuit being set up or released by an ISUP message. For example, the circuit identification code may identify a voice trunk or any other transmission medium in the public switched telephone network. Routing label 510 includes addresses for routing MSU 500. For example, routing label 510 includes originating point code (OPC) field 512, destination point code (DPC) field 514, and signaling link selection field 516. Originating point code field 512 stores the point code of the SS7 node that originated the message. Destination point code field 514 stores the point code of the SS7 node to which the message is to be routed. Signaling link code field 516 stores a signaling link code that indicates the signaling link used to route the message.
The signaling information stored in service information field 504 may be useful in generating call detail records. For example, a call duration billing system may require information regarding call setup, call teardown, and voice trunk used. This information is contained in ISUP messages. In an ISUP message sequence, it is necessary to determine the message type to properly sequence ISUP messages. Information in CIC field 308 and routing label field 310, such as OPC and DPC may be useful to correlate messages. Accordingly, parser 404 illustrated in Figure 4 may extract one or more of these fields from MSU 500 generating a call detail record for a call duration billing application.
Service indicator octet (SIO) field 518 identifies the level 4 protocol of the message. For example, the SIO field may indicate that the level 4 protocol is ISUP, transaction capabilities application part (TCAP), or mobile application part (MAP). This information may also be useful in order to generate CDRs. Accordingly, parser 404 illustrated in Figure 2 may also extract values from SIO field 518 of MSU 500. The remaining fields in MSU 500 are used by lower level SS7 software for error detection and retransmission. For example, forward indicator bit field 520 and backwards indicator bit field 522 contain values utilized to control retransmission of messages. Forward sequence number field 524 and backwards sequence number field 526 contain values for sequencing SS7 messages. Link indicator field 528 stores a value representing the length of message signal unit 500. This field is useful to allow determination of the type of signal unit being received. For example, if the value in the length indicator field is greater than two, the signal unit is a message signaling unit. Flag field 530 stores bits that indicate the start of an SS7 message. These remaining fields are generally not used in CDR generation but a discussion thereof is included herein for completeness.
Figure 6 is a block diagram illustrating exemplary components of parser 404. In Figure 6, parser 404 includes a parser engine 600, a user- configurable desired parameters database 602, and a parameter extraction instructions database 604. Parser engine 600 is a program configured to read desired message parameters information from database 602 to determine the parameters to extract from incoming MSUs. Parser engine 600 then reads instructions for extracting the desired parameters form database 604 and follows the instructions to extract the desired parameters. Desired parameters database 602 contains parameters that are desired to be extracted from incoming MSUs. In a preferred embodiment, desired parameters database 602 comprises a user-editable text file that allows a user to set parameters to be extracted from MSUs, according to the needs of a particular application. For example, a call duration billing application may require CIC, OPC and DPC values. The database user may configure database 602 to include these desired parameters. Accordingly, when parser engine 600 receives an MSU, parser engine 600 reads each desired parameter listed in database 602 and attempts to extract the parameter using instructions provided in database 604.
Database 604 contains instructions for extracting parameters from MSUs. For example, each entry in database 604 may include a first field 606 that corresponds to one of the desired parameters in database 602 and a second field 608 that contains instructions for extracting the desired parameter. For example, parameters for first field 606 may include CIC, OPC, and DPC. Exemplary instructions for extracting the CIC from an MSU are as follows:
1) Go to offset for SIO
2) Compare SIO value to value for ISUP 3) If SIO value = ISUP, go to offset for CIC
4) Extract CIC
Instructions for extracting other parameters that are included in all MSUs, such as OPC and DPC, may simply involve going to the offset and reading the value. Still other parameters, such as Called Party (CdPA) and Calling Party (CgPA) require extremely complex instructions. For example, in order to extract the CdPA parameter, the instructions are as follows:
1. Goto offset for SIO;
2. Compare SIO value to value designated for ISUP; 3. If SIO value is equal to ISUP value, then goto offset for ISUP message type;
4. If ISUP message type is equal to Initial Address Message (IAM), then goto offset for CdPA number pointer;
5. Add contents of CdPA number pointer to current offset; 6. Get length of CdPA number;
7. Add two octets to offset; and
8. Get variable length CdPA number.
Using a user-configurable text file and an extraction instructions database to control parameter extraction from MSUs makes parser functionality easily modifiable. A user need not know anything more than the parameter name to extract the parameter. The parameter extraction instructions database removes the need for the user to remember how or where to locate a parameter. Thus, the parser according to the present embodiment can be easily configured to extract MSU parameters for a variety of applications.
Once parser 404 parses an incoming MSU, the parsed message is forwarded to correlator 406 for correlation processing. Figure 7 illustrates exemplary steps that may be performed by correlator 406 illustrated in Figure 4 in correlating ISUP messages. The steps illustrated in Figure 7 assume a configuration similar to that illustrated in Figure 1 where a CDR generator program is associated with each STP of a mated pair of STPs.
It is understood that the steps illustrated in Figure 7 may be implemented as computer program product including computer-executable instructions embodied in a computer readable medium. Alternatively, the steps illustrated in Figure 7 may be implemented in hardware, such as an application-specific integrated circuit. Any combination of hardware and software for performing the steps illustrated in Figure 7 or any of the other MSU or CDR processing steps described herein is within the scope of the invention.
Referring to Figure 7, in step ST1, correlator 406 receives MSU data from parser 404 or from the other CDR generator. The MSU data includes fields extracted by parser 404 for a specific application. In step ST2, correlator 406 determines whether the received MSU data relates to a new call. Determining whether the received MSU data relates to a new call may include examining the ISUP message type. For example, for ISUP messages, if the message is an IAM message, correlator 406 may determine that the message relates to a new call. In step ST2, if correlator 406 determines that the message relates to a new call, in step ST3 correlator 406 creates a new CDR for the call. Correlator 406 then returns to step ST1 to process the next message.
In step ST2, if correlator 406 determines that the message does not relate to a new call, in step ST4 correlator 406 then determines whether the message relates to the call originating at the receiving CDR generator program. In order to make this determination, correlator 406 preferably compares one or more fields from the MSU data to a database of active CDRs at the receiving site. If correlator 406 determines that the MSU relates to a call originating at the receiving CDR generator program, in step ST5 correlator 406 locates the previously created CDR for the call and stores the MSU data in that record. In step ST4, if correlator 406 determines that the call did not originate at this CDR generator program, in step ST6 correlator 406 forwards the MSU data to the other CDR generator program. The other CDR generator program receives the MSU data and performs the same steps illustrated in Figure 7 to store the MSU data in the same steps in the appropriate CDR. Thus, by forwarding MSU data to the CDR generator that originally created the CDR, correlator 406 according to the present embodiment greatly simplifies CDR correlation over prior art systems.
While Figure 7 illustrates exemplary correlation processing for ISUP messages, Figure 8 illustrates exemplary correlation processing for TCAP messages. Like the steps illustrated in Figure 7, the steps illustrated in Figure 8 assume a configuration similar to that illustrated in Figure 1 where a CDR generator program is associated with each STP of a mated pair of STPs. The steps illustrated in Figure 8 generate a CDR at one or the other monitoring devices for a TCAP query and response. The steps illustrated in Figure 8 are designed to generate a correct CDR even when a race condition occurs due to detection of a TCAP response by a monitoring device before detection of a TCAP query by the other monitoring device. For example, in TCAP line interface database (LIDB) transactions, the TCAP query may be sent through one STP of a mated pair of STPs and the response may be sent through the other STP of the mated pair. If monitoring devices are deployed at both STPs of the mated pair, for example as illustrated in Figure 1 , one monitoring device may receive a LIDB response before the other monitoring device receives the LIDB query. The steps illustrated in Figure 8 demonstrate correlation of the query and response to generate a single correct CDR at one of the STPs, even when this condition occurs.
Referring to Figure 8, in step ST1 correlator 406 receives a TCAP message from the parser or from the other CDR generator program. The TCAP message may be an entire TCAP MSU or any subset of the fields required for CDR generation. In step ST2, correlator 406 determines whether the TCAP message is a query or a response. If the TCAP message is a response, in step ST3 correlator 406 determines whether the response was sent from the other CDR generator program. This condition occurs if the other CDR generator program received the response and did not have a CDR file query corresponding to the response. If in step ST3 correlator 406 determines that the response originated from the other CDR generator, in steps ST4 and ST5 correlator 406 determines whether a CDR containing a query corresponding to the response is present at this CDR generator. This determination may include comparing fields in the response to fields in an active CDR database. If a CDR with a query corresponding to the response is present, in step ST6 correlator 406 stores the response in the CDR with the query and returns to step ST1 to process the next message. If a CDR with a query corresponding to the response is not present, in step ST7 correlator 406 opens a CDR for the response and returns to step ST1 to process the next message. ln step ST3, if correlator 406 determines that the response is not from the other CDR generator, then the response was received from the parser at this CDR generator. Accordingly, in step ST7 correlator 406 checks for a CDR containing the query corresponding to the response at this CDR generator. In step ST8, if a CDR containing the query is present, correlator 406 proceeds to step ST9 and stores the response in the CDR with the query. Correlator 406 then returns to step ST1 to process the next message. In step ST7, if correlator 406 determines that a CDR with a query corresponding to the response is not present, in step ST9 correlator 406 forwards the response to the other CDR generator. Correlator 406 then returns to step ST1 to process the next message.
In step ST2, if correlator 406 determines that the TCAP message received from the parser is a query, in steps ST10 and ST11 correlator 406 checks for a CDR containing a response forwarded from the other CDR generator program. In step ST11 , if correlator 406 determines that a response CDR is present, in step ST12 correlator 406 stores the query in the CDR with the response. Correlator 406 then returns to step ST1 to process the next message. In step ST11 , if correlator 406 determines that a response CDR is not present, in step ST13 correlator 406 opens a new CDR for the query and stores the query in that CDR. Correlator 406 then returns to step ST1 to process the next message.
As stated above, the steps performed by correlator 406 in Figure 8 avoid race conditions. For example, if a response is received at one CDR generator before the other CDR generator receives a query, the response is forwarded to the other CDR generator. The other CDR generator, in response to receiving the response forwarded from the first CDR generator, opens a new CDR containing the response. When the query arrives at the CDR generator that received the forwarded response, the CDR generator stores the query in the CDR containing the forwarded response. In this manner, proper CDRs are created for TCAP transactions, such as LIDB transactions, even when race conditions occur.
CDR Manager Once the CDR generator creates a CDR, the CDR is forwarded to a CDR manager for storage. Figure 9 is a block diagram of CDR manager 124 illustrated in Figure 2. In Figure 9, CDR manager includes a collector 900 for receiving CDRs from transport block 410 illustrated in Figure 4. Communication with transport block 410 may occur using any suitable protocol for transferring data, such as FTP. Transport block 902 receives CDRs from collector 900 and transports the CDRs to bulk storage 128 via a suitable network communications protocol, such as TCP/IP or UDP/IP.
According to an important aspect of the invention, CDR manager 132 includes an application interface kit 130 that allows third party applications to access CDRs and/or MSUs stored in bulk storage 128. Application interface kit 130 includes a set of application programming interfaces (APIs) that allows applications to access CDRs and/or MSUs in both real time and in bulk. By "real time" it is meant that application interface kit 130 allows an application to change the flow and/or content of CDRs and/or MSUs received by the application in a short time period, e.g., on the order of milliseconds or seconds. Application interface kit 130 includes two separate halves. The first half is a server. The application interface kit server can be part of the CDR manager program and handles all commands and requests from the second half of the application interface kit, the AIK client. In addition, or in the alternative, the application interface kit server can be part of the CDR generator program as illustrated in Figure 4. The application interface kit client is linked into a user application and provides commands that the user application can send to the application interface kit server. The application interface kit server and the application interface kit client can communicate with each other via a TCP/IP connection or other appropriate protocol.
Figure 10(a) illustrates an exemplary CDR generator command data structure provided by application interface kit 130. In Figure 10a, the CDR generator command includes a type field 1000, a command identifier field 1002, a transaction identifier field 1004, and a data length field 1006. In the illustrated example, each field is encoded as one byte in the command data structure. The entire command is encapsulated in a network packet, such as a TCP segment or a UDP datagram, and transmitted between the application and the CDR manager or CDR generator.
Figure 10(b) illustrates exemplary values for command type field 1000 illustrated in Figure 10(a). In Figure 10(b), the first column 1010 includes the bit pattern that encodes each command type. The second column 1012 includes a description of each command type. For example, the bit pattern 00000001 identifies a GET command. The GET command is used to obtain attributes from the CDR manager or CDR generator and statistical information regarding generated CDRs. Examples of attributes that may be obtained are AIK Version, which is associated with compatibility checking, and Active Links, which returns a listing of links with currently active CDR generation. The bit pattern 00000010 identifies the SET command. The SET command is used to control behavior of the CDR generator or CDR manager. For example, the SET command may be used to stop and start the flow of CDRs or MSUs in real time. The bit pattern 0000100 identifies the RESPONSE command. The RESPONSE command is a response to the CDR generator command. Finally, the byte pattern 00001000 identifies the TRAP message. The TRAP message is an asynchronous message sent from the CDR generator program or CDR manager program to an application to provide real time information to the application about ongoing processes. For example, a TRAP CDR message contains information associated with one or more CDR records, and a TRAP Error message contains information associated with error conditions in the system. . Figure 10(c) illustrates exemplary identifiers that may be transmitted in identifier field 1002 of a CDR generation message. In the illustrated table, the first column 1014 includes a bit pattern for each of the supported identifiers. The second column 1016 includes a brief description of each identifier function. In the illustrated table, the bit pattern 00000000 instructs the application interface kit server to stop sending CDRs in real time. The bit 00000001 instructs the application interface kit server to start sending CDRs in real time without filtering. As used herein, filtering refers to the filtering of MSUs or CDRs based on parameters in the MSUs or CDRs. Instructing the application interface kit server to send CDRs in real time without the filtering means that the CDR generator or CDR manager will send all CDRs created. The bit pattern 10000001 instructs the application interface kit server to start sending CDRs in real time with filtering. A command to start sending CDRs in real time with filtering will be followed by a command that specifies the filtering criteria. Figure 11 illustrates an exemplary data structure for a filter message. In Figure 11 , filter message 1018 includes a parameter name length field 1020, a parameter name field 1022, a value length field 1024, and a value field 1026. Parameter name length field 1020 stores a value that represents the length of the parameter in an appropriate unit, such as bits or bytes. Parameter name field 1022 includes a name for the parameter that is recognizable by the application interface kit server. Exemplary parameter names that may be used as filter criteria includes OPC, DPC, SIO, CIC, etc. Value length field 1024 includes the length of value field 1026, in any appropriate units such as bytes or bits. Value field 1026 includes the value of the parameter specified in parameter name field 1022. For example, if the parameter specified in parameter name field 1022 is OPC, the value specified in value field 1026 may be 2-0-0. In another example, parameter name field 1022 may specify an IP address. In this case, an exemplary value that may be stored in value field 1026 is 255.255.255.255. Thus, by allowing applications to send filtering messages and control filtering in real time, the application interface kit according to embodiments of the present invention allows real time control of MSUs and CDRs received by an application.
Referring back to Figure 10(c), bit pattern 0000010 instructs the application interface kit server to start sending intermediate CDRs in real time without filtering. As used herein, intermediate CDRs refer to CDRs that may not be complete. For example, in a CDR created for a call duration billing application, an intermediate CDR may be some but not all of the messages used to perform call setup or call teardown. Bit pattern 1000100 instructs application interface kit server to start sending intermediate CDRs in real time with filtering. As stated above, such a message is preferably followed by a filtering message, which instructs application interface kit server of the filter criteria.
Bit pattern 00000100 instructs the application interface kit server to stop sending MSUs in real time. Bit pattern 00001000 instrμcts application interface kit server to start sending MSUs in real time without filtering. Bit pattern 10001000 instructs application interface kit server to start sending MSUs in real time with filtering. These commands are similar to the commands described above with regard to CDRs and a description thereof is not repeated herein. Bit pattern 0001000 instructs application interface kit server to retrieve
CDRs in bulk. A SET message containing an identifier to get CDRs in bulk is followed by a CDR/MSU bulk data request message. Figure 12 illustrates an exemplary data structure for a CDR/MSU bulk data request message. In Figure 12, bulk data request message 1028 includes start time field 1030, stop time field 1032, requester IP address field 1034, location length field 1036, and location field 1038. Start and stop time fields 1030 and 1032 specify the range of time for which CDRs are requested. For example, it may be desirable to request all CDRs generated from 8:00 am to 5:00 pm during a given day. Requestor IP address field 1034 stores the IP address of the application requesting CDRs. Location length field 1036 specifies the length of the storage field location. Finally, location field 1038 specifies the location on the application interface kit server for storing CDRs.
In response to receiving bulk data request message 1028, application the interface kit server extracts the appropriate CDRs from bulk storage and initiates an appropriate bulk file transfer protocol such as FTP, to communicate the CDRs to the application interface kit client. Thus, the application interface kit according to embodiments of the present invention allows application to control bulk processing of CDRs.
Referring back to Figure 10(b), bit pattern 001000000 instructs the application interface kit server to retrieve MSUs in bulk. The operation of this command is similar to the command for retrieving CDRs in bulk. Hence, a description thereof is not repeated herein. Bit pattern 01000000 instructs the receiving entity to send user configuration information to the requester. Exemplary user configuration information that may be sent in response to this command includes the monitoring software version of the receiver.
As illustrated in Figures 10a - 10c, 11 , and 12, the application interface kit provides a mechanism for controlling the flow and content of CDRs and/or MSUs in real time. This controllability by applications facilitates application design without requiring modification to the CDR generation or management software. Accordingly, embodiments of the present invention facilitate development of applications that utilize CDRs or MSUs. Examples of such applications include call duration billing, call duration billing verification, interconnect billing verification, looping detection, mass call detection, fraud detection, such as calling card fraud detection, etc. CDR Examples Both call duration billing and fraud detection applications may require CDRs containing a record of ISUP messages exchanged during a call. An example of ISUP CDR content is as follows: Initial address message (1AM)
Time stamp
OPC
DPC
CIC Called party number
Carrier identification
Generic address
Generic digits
Generic name Original called number
Redirecting number
Redirection information
User service information
Charge number Calling party number
Answer message (ANM) Time stamp
Release message (REL) Time stamp
Release calls
Another example of CDR content that may be generated by embodiments of the present invention includes TCAP messages. Such CDRs may be generated for an interconnect billing application, an interconnect billing verification application, or a calling card fraud detection application. An example of TCAP CDR content is as follows:
LIDB query message Time stamp OPC DPC
Transaction ID (TXID) PIN number Billing number Calling party number
Called party number
LIDB normal response message
LIDB error response message
Company ID
PIN restriction
Record status
CCAN service denial
PIN service denial
The present invention is not limited to generating the CDRs listed above. As stated earlier, the present invention is adaptable to generate CDRs containing any content from an SS7 MSU. Such content is modifiable simply by altering desired parameters in the parameters database accessed by the parser or by sending filtering commands to the application interface kit server.
It will be understood that various details of the invention may be changed without departing from the scope of the invention. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation — the invention being defined by the claims.

Claims

CLAIMS What is claimed is:
1. A system for collecting and processing SS7 message signal units (MSUs), the system comprising: (a) a link interface for copying SS7 MSUs from at least one of an SS7 signaling link and a TCP/IP signaling link;
(b) a call detail record (CDR) generator in communication with the link interface for receiving MSUs copied by the link interface and parsing the MSUs to extract parameters from the MSUs; and
(c) an application interface kit for receiving commands from an application and controlling the flow of the parameters to the application in real time.
2. The system of claim 1 wherein the application interface kit is responsive to commands for delivering CDRs to the application in real time.
3. The system of claim 1 wherein the application interface kit is responsive to commands for delivering MSUs to the application in real time.
4. The system of claim 1 wherein the application interface kit includes a server for receiving the commands and accessing CDRs and MSUs produced by the CDR generator in response to the commands and a client for linking with the application and providing the commands to the server.
5. The system of claim 4 wherein the client and the server communicate via a TCP/IP connection.
6. The system of claim 4 wherein the client and the server communicate using UDP/IP datagrams.
7. The system of claim 1 wherein the application interface kit is responsive to commands for delivering CDRs to the application in bulk.
8. The system of claim 1 wherein the application interface kit is responsive to commands for filtering the MSU parameters delivered to the application in real time.
9. The system of claim 1 wherein the link interface, the call detail record generator, and the application interface kit are adapted to be co- located with and external to a signal transfer point (STP).
10. The system of claim 1 wherein the link interface, the call detail record generator, and the application interface kit are adapted to be internal to a signal transfer point (STP).
11. A system for generating call detail records (CDRs), the system comprising:
(a) a receiver for receiving first SS7 message signal unit (MSU) parameters generated by a CDR generator program associated with a first monitoring device in an
SS7 network;
(b) a collector for receiving SS7 message signal units (MSUs) copied from at least one of an SS7 signaling link and a TCP/IP signaling link; (c) a parser coupled to the collector for receiving the MSUs from the collector and parsing the MSUs to produce second message signal unit parameters; and (d) a correlator coupled to the parser and the receiver for receiving the first and second MSU parameters and producing correlated call detail records from the MSU parameters.
12. The system of claim 11 wherein the parser comprises:
(a) a desired parameters database for storing parameters to be included in the CDRs;
(b) an extraction instructions database for storing instructions for extracting parameters from the MSUs; and (c) a parser engine for accessing the desired parameters database and the extraction instructions database to extract parameters from the MSUs.
13. The system of claim 12 wherein the desired parameters database includes an originating point code (OPC) parameter, a destination point code (DPC) parameter, and a circuit identification code (CIC) or Transaction ID (TXID) parameter, and the extraction instructions database includes instructions for extracting the OPC, DPC, CIC and TXID parameters from an MSU.
14. The system of claim 11 wherein the correlator is adapted to produce CDRs including ISDN user part (ISUP) MSUs for a call duration billing application.
15. The system of claim 11 wherein the correlator is adapted to produce CDRs including transaction capabilities application part (TCAP) MSUs for a billing or billing verification application.
16. The system of claim 11 wherein the correlator is adapted to produce CDRs including ISDN user part (ISUP) and transaction capabilities application part (TCAP) MSUs for a calling card fraud detection application.
17. The system of claim 1 1 wherein the correlator is adapted to produce CDRs including ISDN user part (ISUP) and transaction capabilities application part (TCAP) MSUs for a looping detection application.
18. The system of claim 11 wherein the correlator is adapted to produce CDRs including ISDN user part (ISUP) MSUs and transaction capabilities application part (TCAP) MSUs for a mass call detection application.
19. The system of claim 11 comprising a CDR manager coupled to the correlator for receiving the call detail records from the correlator and storing the CDRs in a bulk storage medium.
20. The system of claim 19 comprising an application interface kit associated with the CDR manager for allowing an application to access the
CDRs stored in the bulk storage medium.
21. The system of claim 20 wherein the application interface kit includes a server associated with the CDR manger for processing commands received from the application for accessing the CDRs in the bulk storage medium and a client associated with the application for generating the commands.
22. The system of claim 21 wherein the client is adapted to produce a filter command for instructing the server to filter CDRs extracted from the bulk storage medium.
23. The system of claim 21 wherein the client is adapted to produce a CDR generation command for instructing the server to send CDRs extracted from the bulk storage medium to the client.
24. The system of claim 21 wherein the client is adapted to produce a stop command for instructing the server to stop sending CDRs extracted from the bulk storage medium to the client.
25. A method for generating call detail records (CDRs) based on SS7 message signal units (MSUs), the method comprising: (a) at a first monitoring device coupled to a first signaling link associated with a first signal transfer point of a mated pair of signal transfer points, receiving, from the first signaling link, a first SS7 MSU associated with a first call; (b) extracting at least one parameter from the first SS7
MSU; (c) determining whether a call detail record exists for the first call at the first monitoring device based on the parameter; and (d) in response to determining that a call detail record does not exist at the first monitoring device, forwarding the parameter to a second monitoring device coupled to a second signaling link associated with a second signal transfer point of the mated pair of the signal transfer points.
26. The method of claim 25 wherein receiving a first SS7 MSU includes receiving a first IDSN user part (ISUP) MSU.
27. The method of claim 25 wherein forwarding the parameter to the second monitoring device includes forwarding the parameter over a TCP/IP interface.
28. The method of claim 25 wherein forwarding the parameter to the second monitoring device includes forwarding the first parameter over a UDP/IP interface.
29. The method of claim 25 comprising, in response to receiving the parameter at the second monitoring device, creating a call detail record for the parameter.
30. The method of claim 25 wherein forwarding the parameter to second monitoring device includes forwarding the parameter without creating a CDR at the first monitoring device.
31. The method of claim 25 wherein receiving the first SS7 MSU from the first signal link includes receiving the first SS7 MSU from a first SS7 signaling link.
32. The method of claim 25 wherein receiving the first SS7 MSU from the first signaling link includes receiving the first SS7 MSU from a first TCP/IP signaling link.
33. A method for generating call detail records based on transaction capabilities application part (TCAP) message signal units (MSUs), the method comprising:
(a) at a first monitoring device, receiving a TCAP response MSU;
(b) extracting at least one response parameter from the TCAP response MSU;
(c) determining whether a CDR associated with a query corresponding to the TCAP response MSU is present at the first monitoring device based on the response parameter; and (d) in response to determining that the CDR associated with the query is not present, forwarding the response parameter to a second monitoring device.
34. The method of claim 33 comprising:
(e) at the second monitoring device, receiving the response parameter forwarded from the first monitoring device;
(f) determining whether a CDR associated with a query corresponding to the response parameter is present at the second monitoring device; and
(g) in response to determining that the CDR is not present at the second monitoring device, opening a CDR for the response parameter at the second monitoring device and storing the response parameter in the CDR at the second monitoring device.
35. The method of claim 34 comprising, at the second monitoring device, in response to receiving a TCAP query MSU corresponding to the TCAP response MSU, extracting at least one query parameter from the MSU and storing the query parameter in the CDR at the second monitoring device containing the response parameter.
36. A computer program product comprising computer-executable instructions embodied in a computer-readable medium for performing steps comprising:
(a) parsing first message signal units (MSUs) copied from at least one of an SS7 signaling link and a TCP/IP signaling link associated with a first signal transfer point (STP) to produce first MSU parameters; (b) receiving second MSU parameters derived from MSUs copied from at least one of an SS7 signaling link and a
TCP/IP signaling link associated with a second signal transfer point; (c) correlating the first and second MSU parameters to produce call detail records (CDRs);
(d) receiving commands from an application for controlling the flow of CDRs to the application; and
(e) controlling the flow of CDRs to the application based on the commands.
37. The computer program product of claim 36 wherein receiving commands from an application includes receiving a command for delivering CDRs to the application in real time and wherein controlling the flow of CDRs to the application includes delivering the CDRs to the application in real time.
38. The computer program product of claim 36 comprising receiving a filter command for filtering CDRs delivered to the application and filtering the CDRs delivered to the application based on the filter command.
39. The computer program product of claim 38 wherein receiving a filter command includes receiving a filter command including at least one MSU parameter value and wherein filtering the CDRs delivered to the application includes transmitting CDRs to the application having the MSU parameter value.
40. The computer program product of claim 36 wherein parsing SS7 MSUs includes reading desired parameters from a desired parameters database, reading instructions for extracting the desired parameters from an extraction instructions database, and extracting the desired parameters from the MSUs based on the instructions.
41. The computer program product of claim 36 wherein correlating the first and second MSU parameters includes creating a single call detail record for the first and second MSU parameters.
PCT/US2000/008123 1999-04-05 2000-03-28 Methods and systems for collecting and processing signaling system 7 (ss7) message signal units (msus) WO2000060844A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AT00919712T ATE519329T1 (en) 1999-04-05 2000-03-28 METHOD AND SYSTEMS FOR RECORDING AND PROCESSING MESSAGE CHARACTER UNITS (MSU) OF THE SIGNING SYSTEM NO.7
AU40354/00A AU4035400A (en) 1999-04-05 2000-03-28 Methods and systems for collecting and processing signaling system 7 (ss7) message signal units (msus)
EP00919712A EP1169845B1 (en) 1999-04-05 2000-03-28 Methods and systems for collecting and processing signaling system 7 (ss7) message signal units (msus)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12788999P 1999-04-05 1999-04-05
US60/127,889 1999-04-05

Publications (1)

Publication Number Publication Date
WO2000060844A1 true WO2000060844A1 (en) 2000-10-12

Family

ID=22432485

Family Applications (3)

Application Number Title Priority Date Filing Date
PCT/US2000/003880 WO2000060839A1 (en) 1999-04-05 2000-02-14 Methods and systems for routing signaling messages associated with ported subscribers in a communications network
PCT/US2000/007876 WO2000060821A1 (en) 1999-04-05 2000-03-24 Methods and systems for routing calling name service query messages in a communications network
PCT/US2000/008123 WO2000060844A1 (en) 1999-04-05 2000-03-28 Methods and systems for collecting and processing signaling system 7 (ss7) message signal units (msus)

Family Applications Before (2)

Application Number Title Priority Date Filing Date
PCT/US2000/003880 WO2000060839A1 (en) 1999-04-05 2000-02-14 Methods and systems for routing signaling messages associated with ported subscribers in a communications network
PCT/US2000/007876 WO2000060821A1 (en) 1999-04-05 2000-03-24 Methods and systems for routing calling name service query messages in a communications network

Country Status (7)

Country Link
US (2) US6639981B1 (en)
EP (4) EP1173969B1 (en)
AT (4) ATE359663T1 (en)
AU (3) AU3491600A (en)
DE (3) DE60034329T2 (en)
ES (1) ES2370995T3 (en)
WO (3) WO2000060839A1 (en)

Families Citing this family (119)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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)
US7002988B1 (en) 1998-12-04 2006-02-21 Tekelec Methods and systems for communicating SS7 messages over packet-based network using transport adapter layer interface
IL130894A (en) 1999-07-12 2003-12-10 Ectel Ltd Method and system for creating combined call detail records database (cdr) in management systems of telecommunications networks
IL130893A (en) * 1999-07-12 2003-12-10 Ectel Ltd Method and system for creating integrated call detail records (cdr) databases in management systems of telecommunications networks
DE19949316A1 (en) * 1999-10-13 2001-04-19 Alcatel Sa Method for transmitting service signaling messages, switching center, conversion node and service control node
KR100394740B1 (en) * 1999-10-28 2003-08-14 엘지전자 주식회사 method for screen message transmission prevention in No.7 signaling network
US7092505B2 (en) * 1999-12-23 2006-08-15 Tekelec Methods and systems for universal, automatic service selection in a telecommunications signaling network
US6781954B1 (en) * 2000-01-12 2004-08-24 Nokia Networks Oy Transfer of SS7 signalling message contents over packet broadcasting network (LAN) from multiple signalling points to single point (multiple point-to-point)
US7701925B1 (en) * 2000-03-22 2010-04-20 Tekelec Presence registration and routing node
US7110773B1 (en) 2000-04-11 2006-09-19 Telecommunication Systems, Inc. Mobile activity status tracker
DE10022764A1 (en) * 2000-05-10 2001-11-15 Siemens Ag Switching system, especially digital switching system, has improved message distributor with internal bus for direct connection of signaling control unit to coupling network
US7318091B2 (en) 2000-06-01 2008-01-08 Tekelec Methods and systems for providing converged network management functionality in a gateway routing node to communicate operating status information associated with a signaling system 7 (SS7) node to a data network node
US6539384B1 (en) * 2000-06-02 2003-03-25 Bellsouth Intellectual Property Corporation Browser on test equipment
US7886054B1 (en) * 2000-10-11 2011-02-08 Siddhartha Nag Graphical user interface (GUI) for administering a network implementing media aggregation
US7266683B1 (en) 2001-07-27 2007-09-04 Siddhartha Nag Selective encryption of application session packets
US7774468B1 (en) 2000-07-28 2010-08-10 Siddhartha Nag Network traffic admission control
US7788354B2 (en) * 2000-07-28 2010-08-31 Siddhartha Nag End-to-end service quality in a voice over Internet Protocol (VoIP) Network
US7013338B1 (en) 2000-07-28 2006-03-14 Prominence Networks, Inc. Multiplexing several individual application sessions over a pre-allocated reservation protocol session
US7227927B1 (en) * 2000-09-08 2007-06-05 Tekelec Scalable call processing node
US6741685B1 (en) * 2000-09-29 2004-05-25 Agilent Technologies, Inc. Billing systems and methods for communication networks providing differentiated services
US7050549B2 (en) * 2000-12-12 2006-05-23 Inrange Technologies Corporation Real time call trace capable of use with multiple elements
US6842513B1 (en) * 2001-03-16 2005-01-11 At&T Corp. Method and apparatus for providing telecommunications services
US20020150221A1 (en) * 2001-04-12 2002-10-17 Carson Douglas John Generating call detail records
EP1402355B1 (en) * 2001-05-23 2018-08-29 Tekelec Global, Inc. Methods and systems for automatically configuring network monitoring system
EP1309208A1 (en) * 2001-10-24 2003-05-07 Agilent Technologies, Inc. (a Delaware corporation) Call monitoring method and system
EP1466465B1 (en) 2001-12-20 2018-01-24 Tekelec Global, Inc. Database driven methods and systems for real time call tracing
US7222192B2 (en) * 2002-01-10 2007-05-22 Tekelec Methods and systems for providing mobile location management services in a network routing node
GB0201915D0 (en) * 2002-01-29 2002-03-13 Intellprop Ltd Telecommunications services apparatus
US20030153357A1 (en) * 2002-02-11 2003-08-14 Anders Lundh Apparatus and method for determining an address in a telecommunication network
ATE502467T1 (en) * 2002-05-02 2011-04-15 Tekelec Us FILTERING AND APPLICATION TRIGGER PLATFORM
US20030215081A1 (en) * 2002-05-15 2003-11-20 Souza Lopes Vicente Melillo De Triggerless call type blocking system and method in a telecommunications network
US7076474B2 (en) * 2002-06-18 2006-07-11 Hewlett-Packard Development Company, L.P. Method and system for simulating a business process using historical execution data
US6914973B2 (en) * 2002-06-25 2005-07-05 Tekelec Methods and systems for improving trunk utilization for calls to ported numbers
US7254109B2 (en) * 2002-07-12 2007-08-07 Baypackets, Inc. Fault tolerant correlation engine method and system for telecommunications networks
US7609612B2 (en) * 2002-07-12 2009-10-27 Texas Instruments Incorporated Multi-carrier transmitter for ultra-wideband (UWB) systems
US7130397B2 (en) * 2002-08-05 2006-10-31 Alcatel Apparatus, and an associated method, for detecting a mass call event and for ameliorating the effects thereof
US6993318B2 (en) * 2002-08-05 2006-01-31 Technocom Corporation System and method for network assisted calibration in a wireless network
US7848767B2 (en) 2002-10-15 2010-12-07 Tekelec Methods and systems for migrating between application layer mobile signaling protocols
US7215748B2 (en) * 2002-12-12 2007-05-08 Tekelec Methods and systems for defining and distributing data collection rule sets and for filtering messages using same
US7190772B2 (en) * 2003-02-27 2007-03-13 Tekelec Methods and systems for automatically and accurately generating call detail records for calls associated with ported subscribers
US7206394B2 (en) * 2003-03-10 2007-04-17 Tekelec Methods and systems for dynamic, rules-based peg counting
US7440557B2 (en) * 2003-08-08 2008-10-21 Gnd Engineering, Pllc System and method for auditing a communications bill
US6970542B2 (en) * 2003-09-03 2005-11-29 Tekelec Methods and systems for identifying calls connected without answer supervision and for automatically generating billing information for the calls
US7301910B2 (en) * 2003-11-06 2007-11-27 Tekelec Methods and systems for automated analysis of signaling link utilization
US7127057B2 (en) * 2003-11-07 2006-10-24 Tekelec Methods and systems for distributing application data among multiple processing modules in a telecommunications network element having a distributed internal processing architecture
US7072678B2 (en) 2003-11-20 2006-07-04 Tekelec Methods and systems for triggerless mobile group dialing
US7496185B1 (en) 2003-12-30 2009-02-24 Mantas, Inc. System and method of collecting, correlating and storing telecom data as call detail records
WO2005069898A2 (en) * 2004-01-16 2005-08-04 Tekelec Methods, systems, and computer program products for providing configurable telecommunications detail record adapter
US7933608B2 (en) * 2004-03-11 2011-04-26 Tekelec Methods, systems, and computer program products for providing presence gateway functionality in a telecommunications network
US7146181B2 (en) * 2004-03-11 2006-12-05 Tekelec Methods and systems for delivering presence information regarding push-to-talk subscribers
EP1766955A2 (en) * 2004-06-18 2007-03-28 Tekelec METHODS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR SELECTING OR GENERATING A SINGLE CALL DETAIL RECORD (CDR) FROM A PLURALITY OF CDRs ASSOCIATED WITH A CALL HAVING A PLURALITY OF LEGS
US20050287983A1 (en) * 2004-06-28 2005-12-29 Armanino Frederick M System and method of managing SS7-monitored call information
US7406159B2 (en) * 2004-07-15 2008-07-29 Tekelec Methods, systems, and computer program products for automatically populating signaling-based access control database
US7577245B2 (en) * 2004-07-29 2009-08-18 At&T Intellectual Property I, L.P. Method of detecting misrouted inter-office transport facility routes in a telecommunications system
US7580837B2 (en) 2004-08-12 2009-08-25 At&T Intellectual Property I, L.P. System and method for targeted tuning module of a speech recognition system
US7003080B1 (en) * 2004-09-23 2006-02-21 Verizon Services Corp. Methods and apparatus for reducing data capture and storage requirements for call and transaction related message monitoring and fraud detection
US7864942B2 (en) 2004-12-06 2011-01-04 At&T Intellectual Property I, L.P. System and method for routing calls
US7242751B2 (en) 2004-12-06 2007-07-10 Sbc Knowledge Ventures, L.P. System and method for speech recognition-enabled automatic call routing
US7783024B1 (en) 2004-12-16 2010-08-24 At&T Intellectual Property Ii, L.P. Method and apparatus for providing special call handling for valued customers of retailers
US7751551B2 (en) 2005-01-10 2010-07-06 At&T Intellectual Property I, L.P. System and method for speech-enabled call routing
US7603479B2 (en) * 2005-02-02 2009-10-13 At&T Mobility Ii Llc Portable diagnostic device for trouble-shooting a wireless network and a method for trouble-shooting a wireless network
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
US8428074B2 (en) 2005-04-29 2013-04-23 Prom Ks Mgmt Limited Liability Company Back-to back H.323 proxy gatekeeper
US8204052B2 (en) * 2005-05-02 2012-06-19 Tekelec, Inc. Methods, systems, and computer program products for dynamically coordinating collection and distribution of presence information
US7640015B2 (en) * 2005-05-12 2009-12-29 Agilent Technologies, Inc. Tools, methods and systems of storing remotely and retrieving detail records given a specific call or data session
US7657020B2 (en) 2005-06-03 2010-02-02 At&T Intellectual Property I, Lp Call routing system and method of using the same
US7398084B2 (en) * 2005-06-29 2008-07-08 Agilent Technologies, Inc. Method and system of correlating dissimilar call records to a high level aggregated view
US7738648B1 (en) 2005-06-30 2010-06-15 Tekelec Methods, systems and computer program products for rerouting specific services traffic from a signaling message routing node
US7668534B2 (en) * 2005-07-05 2010-02-23 Agilent Technologies, Inc. Method and system for transportation of derived call records to a central repository
US8005457B2 (en) * 2005-09-02 2011-08-23 Adrian Jones Method and system for verifying network resource usage records
US20070121908A1 (en) * 2005-10-07 2007-05-31 Tekelec Methods, systems, and computer program products for providing address translation using subsequent address information
US7907713B2 (en) * 2005-10-25 2011-03-15 Tekelec Methods, systems, and computer program products for using a presence database to deliver enhanced presence information regarding communications made to or from a presentity
GB2431826A (en) * 2005-10-28 2007-05-02 Agilent Technologies Inc Correlating signalling and bearer circuits in a mobile communication network
US7889716B2 (en) 2005-12-01 2011-02-15 Tekelec Methods, systems, and computer program products for using an E.164 number (ENUM) database for message service message routing resolution among 2G and subsequent generation network systems
US7395187B2 (en) * 2006-02-06 2008-07-01 International Business Machines Corporation System and method for recording behavior history for abnormality detection
CN101433070B (en) 2006-02-15 2011-10-05 泰克莱克公司 Methods, systems, and computer program products for selectively processing or redirecting signaling connection control part (SCCP) messages
US7787445B2 (en) 2006-07-20 2010-08-31 Tekelec Methods, systems, and computer program products for routing and processing ENUM queries
US8254551B2 (en) 2006-12-07 2012-08-28 Tekelec, Inc. Methods, systems, and computer program products for providing quality of service using E.164 number mapping (ENUM) data in a communications network
US8073127B2 (en) * 2007-02-21 2011-12-06 Tekelec Methods, systems, and computer program products for using a location routing number based query and response mechanism to effect subscriber cutover
US20080198996A1 (en) * 2007-02-21 2008-08-21 Tekelec Methods, systems, and computer program products for using a location routing number based query and response mechanism to effect advanced routing
US8213440B2 (en) 2007-02-21 2012-07-03 Tekelec Global, Inc. Methods, systems, and computer program products for using a location routing number based query and response mechanism to route calls to IP multimedia subsystem (IMS) subscribers
US8799158B2 (en) * 2007-02-23 2014-08-05 Kyocera Corporation Automated bill validation for electronic and telephonic transactions
US8452890B2 (en) * 2007-02-26 2013-05-28 Performance Technologies Inc. Point code emulation for common channel signaling system No. 7 signaling network
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
US9379898B2 (en) 2007-05-04 2016-06-28 Tekelec, Inc. Methods, systems, and computer program products for providing billing and usage data to downstream applications
US7996541B2 (en) 2007-06-15 2011-08-09 Tekelec Methods, systems, and computer program products for identifying a serving home subscriber server (HSS) in a communications network
US8254553B2 (en) * 2007-08-10 2012-08-28 Tekelec, Inc. Systems, methods, and computer program products for number translation with local directory number support
US20090041223A1 (en) * 2007-08-10 2009-02-12 Devesh Agarwal Systems, methods, and computer readable media for triggerless call redirection with release
US8538000B2 (en) 2007-08-10 2013-09-17 Tekelec, Inc. Methods, systems, and computer program products for performing message deposit transaction screening
US8594679B2 (en) 2008-03-07 2013-11-26 Tekelec Global, Inc. Methods, systems, and computer readable media for routing a message service message through a communications network
US8532089B2 (en) * 2008-03-18 2013-09-10 Verizon Patent And Licensing Inc. Call intercept for voice over internet protocol (VoIP)
US8532092B2 (en) * 2008-06-02 2013-09-10 Tekelec, Inc. Methods, systems, and computer readable media for providing next generation network (NGN)-based end user services to legacy subscribers in a communications network
WO2009152512A2 (en) 2008-06-13 2009-12-17 Tekelec Methods, systems, and computer readable media for providing presence data from multiple presence information providers
CN102177749B (en) * 2008-08-01 2016-05-25 泰克莱克股份有限公司 System, method and the computer-readable medium of the triggerless routing/screening based on shift position
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
US8831645B2 (en) 2008-11-24 2014-09-09 Tekelec, Inc. Methods, systems, and computer readable media for providing geo-location proximity updates to a presence system
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
US9219677B2 (en) 2009-01-16 2015-12-22 Tekelec Global, Inc. Methods, systems, and computer readable media for centralized routing and call instance code management for bearer independent call control (BICC) signaling messages
US9021014B2 (en) 2009-03-25 2015-04-28 Tekelec, Inc. Methods, systems, and computer readable media for providing home subscriber server (HSS) proxy
US8452325B2 (en) 2009-05-11 2013-05-28 Tekelec, Inc. Methods, systems, and computer readable media for providing scalable number portability (NP) home location register (HLR)
US8874784B2 (en) 2009-08-10 2014-10-28 Tekelec, Inc. Systems, methods, and computer readable media for controlling social networking service originated message traffic
US8224337B2 (en) 2009-09-16 2012-07-17 Tekelec, Inc. Methods, systems, and computer readable media for providing foreign routing address information to a telecommunications network gateway
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
US9313759B2 (en) 2009-10-16 2016-04-12 Tekelec, Inc. Methods, systems, and computer readable media for providing triggerless equipment identity register (EIR) service in a diameter network
WO2011106690A2 (en) 2010-02-25 2011-09-01 Tekelelec Systems, methods, and computer readable media for using a signaling message routing node to provide backup subscriber information management service
US8649272B2 (en) 2010-05-17 2014-02-11 Tekelec Global, Inc. Methods, systems and computer readable media for mobile-communication-device-initiated network monitoring services
EP2656647B1 (en) 2010-12-23 2019-04-24 Tekelec, Inc. Method, system, and computer readable media for modifying a diameter signaling message directed to a charging function node
EP2666263B1 (en) 2011-01-21 2019-07-24 Tekelec, Inc. Methods, systems, and computer readable media for screening diameter messages within a diameter signaling router (dsr) having a distributed message processor architecture
US8831016B2 (en) 2011-03-18 2014-09-09 Tekelec, Inc. Methods, systems, and computer readable media for configurable diameter address resolution
US9100796B2 (en) 2011-12-15 2015-08-04 Tekelec, Inc. Methods, systems, and computer readable media for seamless roaming between diameter and non-diameter networks
US8855654B2 (en) 2013-01-28 2014-10-07 Tekelec Global, Inc. Methods, systems, and computer readable media for tracking and communicating long term evolution (LTE) handset communication capability
US9363388B2 (en) 2013-02-18 2016-06-07 Tekelec, Inc. Methods, systems, and computer readable media for providing targeted services to telecommunications network subscribers based on information extracted from network signaling and data traffic
US9143942B2 (en) 2013-03-14 2015-09-22 Tekelec Global, Inc. Methods, systems, and computer readable media for providing a multi-network equipment identity register
US9635526B2 (en) 2013-03-15 2017-04-25 Tekelec, Inc. Methods, systems, and computer readable media for utilizing a diameter proxy agent to communicate short message service (SMS) messages
US10117127B2 (en) 2015-07-08 2018-10-30 Oracle International Corporation Methods, systems, and computer readable media for communicating radio access network congestion status information for large numbers of users
US10812663B2 (en) 2018-03-03 2020-10-20 Leo Anthony Wrobel, JR. Apparatus and method for using an intelligent network for analyzing an event external to a signaling network
US11025782B2 (en) 2018-12-11 2021-06-01 EXFO Solutions SAS End-to-end session-related call detail record
US11582258B2 (en) 2021-02-04 2023-02-14 Oracle International Corporation Methods, systems, and computer readable media for mitigating denial of service (DoS) attacks at network functions (NFs)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5008929A (en) 1990-01-18 1991-04-16 U.S. Intelco Networks, Inc. Billing system for telephone signaling network
US5592530A (en) 1995-01-25 1997-01-07 Inet, Inc. Telephone switch dual monitors
US5712908A (en) 1995-12-22 1998-01-27 Unisys Corporation Apparatus and method for generating call duration billing records utilizing ISUP messages in the CCS/SS7 telecommunications network
US6028914A (en) * 1998-04-09 2000-02-22 Inet Technologies, Inc. System and method for monitoring performance statistics in a communications network

Family Cites Families (87)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3917915A (en) 1973-07-09 1975-11-04 Tekno Ind Inc Telephone service observation system
US4162377A (en) 1978-07-13 1979-07-24 Bell Telephone Laboratories, Incorporated Data base auto bill calling using CCIS direct signaling
US4191860A (en) 1978-07-13 1980-03-04 Bell Telephone Laboratories, Incorporated Data base communication call processing method
US4313035A (en) 1980-01-18 1982-01-26 Bell Telephone Laboratories, Incorporated Method of providing person locator service
US4310727A (en) 1980-02-04 1982-01-12 Bell Telephone Laboratories, Incorporated Method of processing special service telephone calls
US4385206A (en) 1980-12-16 1983-05-24 Stromberg-Carlson Corporation Programmable port sense and control signal preprocessor for a central office switching system
US4439636A (en) 1982-03-09 1984-03-27 Martha Newkirk Credit card actuated telecommunication access network
JPS58215164A (en) 1982-06-09 1983-12-14 Hitachi Ltd Charging system
SE432041B (en) 1982-09-07 1984-03-12 Kurt Katzeff DEVICE WITH A PAYMENT CARD USING A PAYMENT SYSTEM
DK608684D0 (en) 1984-12-18 1984-12-18 Gnt Automatic As PAYMENT PHONE
US5572579A (en) * 1995-04-06 1996-11-05 Bell Communications Research, Inc. System and method for providing portable telephone number service
US4756020A (en) 1985-08-30 1988-07-05 American Telephone And Telegraph Company, At&T Bell Laboratories Method and apparatus for disallowing the extension of a call through a network
EP0212654B1 (en) 1985-08-30 1993-10-27 AT&T Corp. Method and apparatus for disallowing the extension of a call through a network
US4897870A (en) 1985-09-25 1990-01-30 Southlake Technologies, Inc. Network implemented pay telephone set
US4897835A (en) 1985-11-27 1990-01-30 At&E Corporation High capacity protocol with multistation capability
JPS62200859A (en) 1986-02-27 1987-09-04 Nec Corp Inter-network communicating call charging system
US4726056A (en) 1986-06-25 1988-02-16 American Telephone And Telegraph Company At&T Bell Laboratories Shared flexible rating of telecommunications calls
US4756019A (en) 1986-08-27 1988-07-05 Edmund Szybicki Traffic routing and automatic network management system for telecommunication networks
US4754479A (en) 1986-09-17 1988-06-28 American Telephone And Telegraph Company Station number portability
CA1276239C (en) 1986-10-01 1990-11-13 Arlene J. Harris Cellular mobile radio credit card system
US4769834A (en) 1987-01-30 1988-09-06 American Telephone And Telegraph Company And At&T Information Systems Inc. Inter-exchange carrier access
US4788718A (en) 1987-10-05 1988-11-29 American Telephone And Telegraph Company, At & T Laboratories Call data collection and modification of received call distribution
US5150357A (en) 1989-06-12 1992-09-22 Emil Hopner Integrated communications system
US4959849A (en) 1989-07-31 1990-09-25 At&T Bell Laboratories End-to-end network surveillance
US4972461A (en) 1989-09-20 1990-11-20 At&T Bell Laboratories Call message delivery system and method
EP0477448B1 (en) 1990-09-28 1995-07-12 Hewlett-Packard Company Network monitoring device and system
US5291481A (en) 1991-10-04 1994-03-01 At&T Bell Laboratories Congestion control for high speed packet networks
CA2086694C (en) 1992-03-05 1996-12-31 Steven K. Miller System, data processing method and program to provide a programmable interface between a workstation and an archive server to automatically store telephone transaction information
JP3098611B2 (en) * 1992-05-19 2000-10-16 株式会社日立製作所 Calling method of communication terminal device
US5430709A (en) 1992-06-17 1995-07-04 Hewlett-Packard Company Network monitoring method and apparatus
US5475732A (en) 1993-02-16 1995-12-12 C & P Of Virginia Common channeling signaling network maintenance and testing
US5506893A (en) 1993-02-19 1996-04-09 At&T Corp. Telecommunication network arrangement for providing real time access to call records
US5457729A (en) 1993-03-15 1995-10-10 Symmetricom, Inc. Communication network signalling system link monitor and test unit
US5426688A (en) 1993-05-12 1995-06-20 Anand; Vivodh Z. J. Telecommunication alarm method and system
US5546398A (en) * 1993-07-23 1996-08-13 Nts Communications, Inc. Signal intercept system and method
EP0658032B1 (en) 1993-12-06 2001-09-26 Agilent Technologies Inc. a Delaware Corporation Location identification in a communications signalling network
US5473596A (en) 1993-12-09 1995-12-05 At&T Corp. Method and system for monitoring telecommunication network element alarms
US5438570A (en) 1993-12-29 1995-08-01 Tekno Industries, Inc. Service observing equipment for signalling System Seven telephone network
DE69530534T2 (en) * 1994-02-25 2004-03-18 Hewlett-Packard Co. (N.D.Ges.D.Staates Delaware), Palo Alto Message receiving circuit for a signaling network
US5539804A (en) 1994-02-25 1996-07-23 Ctel Compression Telecommunications Corporation Common channel signalling communication monitoring system
WO1995034153A1 (en) * 1994-06-08 1995-12-14 Hughes Aircraft Company Apparatus and method for hybrid network access
US5586177A (en) 1995-09-06 1996-12-17 Bell Atlantic Network Services, Inc. Intelligent signal transfer point (ISTP)
US5757895A (en) * 1995-11-09 1998-05-26 Unisys Corporation Extracting and processing data derived from a common channel signalling network
US5579371A (en) 1994-11-22 1996-11-26 Unisys Corporation Common channel signaling network applications platform
US5583926A (en) 1994-12-30 1996-12-10 Stentor Resource Centre Inc. Method and apparatus for routing a call to a number corresponding to a virtual public dial plan or to an existing dial plan
US5768358A (en) 1994-12-30 1998-06-16 Stentor Resource Centre Inc. Method and apparatus for routing a call to a number corresponding to a virtual public dial plan or to an existing dial plan
US5774532A (en) 1995-04-21 1998-06-30 Mci Corporation Single network record construction
US5606600A (en) 1995-05-10 1997-02-25 Mci Communications Corporation Generalized statistics engine for telephone network employing a network information concentrator
US5768352A (en) 1995-05-10 1998-06-16 Mci Communications Corporation Generalized statistics engine for telephone network
US5598464A (en) * 1995-06-20 1997-01-28 Dsc Communications Comporation Method and apparatus for providing local number portability
US5689555A (en) 1995-06-30 1997-11-18 Siemens Stromberg-Carlson Method for transferring a subscriber to a new local service provider
US6009160A (en) 1995-06-30 1999-12-28 Siemens Information And Communication Networks, Inc. Method for routing a call
US5978464A (en) 1995-06-30 1999-11-02 Siemens Information And Communications Networks, Inc. Method for updating a local switch internal database in system having different service providers within a common numbering plan area
US5970131A (en) 1995-06-30 1999-10-19 Siemens Information And Communication Networks, Inc. Method for providing location/geographic portability in a system having different service providers within a common numbering plan area
US5748724A (en) 1995-06-30 1998-05-05 Siemens Stomberg-Carlson Method for transferring a subscriber to a new local service provider
US5625681A (en) * 1995-08-11 1997-04-29 Stratus Computer, Inc. Method and apparatus for telephone number portability
US5740239A (en) 1995-09-27 1998-04-14 Lucent Technologies Inc. Method and apparatus using bit maps to access data for processing telephone calls
JP3763907B2 (en) * 1995-12-12 2006-04-05 エイ・ティ・アンド・ティ・コーポレーション Method for monitoring signaling messages in a communication network
US5764745A (en) 1995-12-15 1998-06-09 Gte Laboratories Incorporated Apparatus and method for local number portability using nongeographic subscriber numbers
CA2165857C (en) 1995-12-21 2000-07-25 L. Lloyd Williams Number portability using isup message option
CA2165856C (en) 1995-12-21 2001-09-18 R. William Carkner Number portability with database query
US5784443A (en) 1996-02-01 1998-07-21 Mci Corporation Integrated revenue domain for telecommunication networks
EP0792074A3 (en) 1996-02-20 1998-11-11 Hewlett-Packard Company A method of providing a service in a switched telecommunications system and a message interceptor suitable for use in such method
AU1865197A (en) 1996-03-08 1997-09-22 Stentor Resource Centre Inc. Providing number portability by means of enhanced routing tables
AU2995897A (en) * 1996-05-03 1997-11-26 Dsc Telecom L.P. System and method for number portability processing in a telecommunications network
US6021126A (en) 1996-06-26 2000-02-01 Bell Atlantic Network Services, Inc. Telecommunication number portability
US6134316A (en) 1996-10-18 2000-10-17 Telefonaktiebolaget Lm Ericsson Telecommunications network with relocateability of subscriber number
US6108782A (en) 1996-12-13 2000-08-22 3Com Corporation Distributed remote monitoring (dRMON) for networks
US6122362A (en) * 1996-12-24 2000-09-19 Evolving Systems, Inc. Systems and method for providing network element management functionality for managing and provisioning network elements associated with number portability
US6137869A (en) 1997-09-16 2000-10-24 Bell Atlantic Network Services, Inc. Network session management
US6097719A (en) * 1997-03-11 2000-08-01 Bell Atlantic Network Services, Inc. Public IP transport network
US6028921A (en) * 1997-06-11 2000-02-22 Bellsouth Intellectual Property Corporation Method and system for delivery of a message to a display unit
US5949865A (en) * 1997-08-18 1999-09-07 Ericsson Inc. Management of calling name delivery in telephone networks providing for telephone number portability
US6108332A (en) 1997-09-12 2000-08-22 Ericsson Inc. Local number portability for interexchange carriers
US6748069B1 (en) 1997-09-19 2004-06-08 Bellsouth Intellectual Property Corp. Method and system for routing calling name queries
US6138023A (en) 1997-09-23 2000-10-24 Lucent Technologies, Inc. Method for porting a directory number from one wireless service provider to another
US6111946A (en) 1998-01-29 2000-08-29 Bell Canada Method and system for providing answer supervision in a switched telephone 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
US6359976B1 (en) 1998-06-08 2002-03-19 Inet Technologies, Inc. System and method for monitoring service quality in a communications network
WO2000016583A1 (en) 1998-09-14 2000-03-23 Curt Wong Method for providing number portability in a telecommunications network
US6134307A (en) 1998-09-21 2000-10-17 Iridium Ip Llc Call conversion process for a business system for a global telecommunications network
US6272136B1 (en) * 1998-11-16 2001-08-07 Sun Microsystems, Incorporated Pseudo-interface between control and switching modules of a data packet switching and load balancing system
US6510164B1 (en) * 1998-11-16 2003-01-21 Sun Microsystems, Inc. User-level dedicated interface for IP applications in a data packet switching and load balancing system
US6424621B1 (en) * 1998-11-17 2002-07-23 Sun Microsystems, Inc. Software interface between switching module and operating system of a data packet switching and load balancing system
US6438223B1 (en) 1999-03-03 2002-08-20 Open Telephone Network, Inc. System and method for local number portability for telecommunication networks
US6466796B1 (en) * 1999-04-01 2002-10-15 Lucent Technologies Inc. System for providing location based service to a wireless telephone set in a telephone system
US6456708B1 (en) 1999-11-12 2002-09-24 Alcatel Usa Sourcing, L.P. Triggerless number portability system and method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5008929A (en) 1990-01-18 1991-04-16 U.S. Intelco Networks, Inc. Billing system for telephone signaling network
US5592530A (en) 1995-01-25 1997-01-07 Inet, Inc. Telephone switch dual monitors
US5712908A (en) 1995-12-22 1998-01-27 Unisys Corporation Apparatus and method for generating call duration billing records utilizing ISUP messages in the CCS/SS7 telecommunications network
US6028914A (en) * 1998-04-09 2000-02-22 Inet Technologies, Inc. System and method for monitoring performance statistics in a communications network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE", November 1998, MICHAEL MCGREW LUCENT TECHNOLOGIES INC., article "Transport SS7 Signalling OverIP; draft- mcgrew-tss7s-00.txt;"

Also Published As

Publication number Publication date
ATE460036T1 (en) 2010-03-15
EP1169829A4 (en) 2003-05-14
EP1169829B1 (en) 2006-10-04
WO2000060839A1 (en) 2000-10-12
EP1173969B1 (en) 2007-04-11
EP1173969A4 (en) 2003-05-14
DE60043954D1 (en) 2010-04-15
WO2000060821A1 (en) 2000-10-12
DE60034329T2 (en) 2007-12-20
US6639981B1 (en) 2003-10-28
DE60031103D1 (en) 2006-11-16
EP1169845B1 (en) 2011-08-03
DE60031103T2 (en) 2007-05-16
ATE341884T1 (en) 2006-10-15
EP1173969A1 (en) 2002-01-23
EP1169845A4 (en) 2008-04-30
ATE359663T1 (en) 2007-05-15
ATE519329T1 (en) 2011-08-15
EP1679848A1 (en) 2006-07-12
ES2370995T3 (en) 2011-12-26
US6327350B1 (en) 2001-12-04
EP1169845A1 (en) 2002-01-09
EP1679848B1 (en) 2010-03-03
AU4035400A (en) 2000-10-23
AU4027300A (en) 2000-10-23
DE60034329D1 (en) 2007-05-24
AU3491600A (en) 2000-10-23
EP1169829A1 (en) 2002-01-09

Similar Documents

Publication Publication Date Title
US6327350B1 (en) Methods and systems for collecting and processing signaling system 7 (SS7) message signal units (MSUs)
US6249572B1 (en) Transaction control application part (TCAP) call detail record generation in a communications network
US6967956B1 (en) Methods and systems for providing message translation, accounting and routing service in a multi-protocol communications network environment
EP1212898B1 (en) Service quality monitoring in a communications network
CA2351375C (en) Systems and methods for communicating messages among ss7 signaling points and internet protocol (ip) nodes using signal transfer points
US5953404A (en) Method and system for providing mediated access between signaling networks
US6400813B1 (en) Mediation system for a telephone network
US20010046856A1 (en) Methods and systems for mobile application part (MAP) screening
EP1679866A1 (en) Intelligent processing for establishing communication over the internet
EP1766955A2 (en) METHODS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR SELECTING OR GENERATING A SINGLE CALL DETAIL RECORD (CDR) FROM A PLURALITY OF CDRs ASSOCIATED WITH A CALL HAVING A PLURALITY OF LEGS
WO2002095580A1 (en) Methods and systems for automatically configuring network monitoring system
WO1999021312A1 (en) Advanced intelligent network gateway
WO2007044689A2 (en) Methods, systems, and computer program products for providing address translation using subsequent address information
US6782004B1 (en) Intelligent network signaling using an open system protocol
CN102378151B (en) Information sharing platform and method thereof
JP4248749B2 (en) Signaling in telecommunications systems
EP1314324B1 (en) Protocol translation, accounting and routing in a gateway
EP1177660B1 (en) Methods and systems for routing signaling messages in a communications network using circuit identification code (cic) information
CA2352246C (en) 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)
DE69828694T2 (en) INTELLIGENT PERIPHERAL SERVICE
EP1303149B1 (en) Data record dissemination system apparatus and method therefor
Sprague et al. Tekelec's Transport Adapter Layer Interface
WO1999001992A2 (en) Ani based routing

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2000919712

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2000919712

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: JP