Source: http://www.google.com/patents/US7295579?dq=6,977,809&ei=-AObT5vAOoSgiQL_5qznDg
Timestamp: 2015-03-05 04:28:35
Document Index: 193491355

Matched Legal Cases: ['art 3', 'art 1', 'art 2', 'art 1', 'art 1', 'art 1', 'art 1', 'art 1', 'art 2', 'art 2', 'art 2', 'art 1', 'art 2', 'art 1', 'art 2', 'art 1', 'art 1', 'art 2']

Patent US7295579 - Methods and systems for communicating signaling information using a ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA normalizing signaling gateway (NSG) routing node receives a first signaling message formatted according to a first variant of a common or standard signaling protocol, such as ISUP, and creates a second signaling message based on the first message. The second signaling message includes a normalized...http://www.google.com/patents/US7295579?utm_source=gb-gplus-sharePatent US7295579 - Methods and systems for communicating signaling information using a normalized signaling protocolAdvanced Patent SearchPublication numberUS7295579 B2Publication typeGrantApplication numberUS 10/164,226Publication dateNov 13, 2007Filing dateJun 5, 2002Priority dateJun 5, 2001Fee statusLapsedAlso published asEP1402669A1, EP1402669A4, US20020186723, WO2002100013A1Publication number10164226, 164226, US 7295579 B2, US 7295579B2, US-B2-7295579, US7295579 B2, US7295579B2InventorsDavid Michael Sprague, Mark Edward Kanode, Dan Alan Brendes, Mark Ernest DavidsonOriginal AssigneeTekelecExport CitationBiBTeX, EndNote, RefManPatent Citations (9), Non-Patent Citations (1), Referenced by (2), Classifications (11), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetMethods and systems for communicating signaling information using a normalized signaling protocol
12. The method of claim 1 wherein receiving a first message which is formatted according to a variant of a first SS7 ISUP protocol includes receiving a message formatted according to the International Telecommunications Union�International (ITU-I) ISUP protocol standard.
17. The network element of claim 13 wherein the first SS7 ISUP protocol is defined by the International Telecommunications Union�International (ITU-I) ISUP protocol standard.
The conventional telecommunications network includes two distinct communication pathways or subnetworks�a voice network and a signaling network. These two networks function in a cooperative manner to facilitate communications between users. As implied by its name, the voice network handles the transmission of voice (or user data) information between users. The signaling network has a number of responsibilities, which include call setup, call teardown, and database access. In simple terms, the signaling network facilitates the dynamic linking together of a number of discrete voice-type communication circuits, such that a voice-type connection is established between the calling and called party. Additionally, the signaling network provides a framework through which non-voice-related information may be transported, with this data and transport functionality being transparent to the users. This signaling technique is often referred to as out-of-band signaling, where the term �band� implies voice band. The signaling protocol most commonly employed in communication networks around the world is the signaling system 7 (SS7) signaling protocol. Different variations of SS7 may be used in different regions.
Signaling links are transmission facilities used to connect one SP to another. Conventional signaling links are dedicated bidirectional facilities operating at 56 kbps in the U.S. and Canada and at 64 kbps when clear channel capability is deployed. The relatively recent emergence of Internet protocol (IP)-based telephony (i.e., IP telephony) has led to a number of new network elements, some of which communicate via both traditional public switched telephone network (PSTN) SS7 and IP based signaling protocols. For instance, a media gateway controller (MGC) is a network element that effectively serves as a bridge between the PSTN and an IP telephony network. That is, an MGC node communicates with and controls one or more media gateway (MG) nodes. Those familiar with PSTN network architectures will appreciate that the functionality provided by an MGC/MG pair (i.e., a �softswitch�) is similar to the functionality provided by a traditional PSTN tandem office switch. In the case of an MGC node, SS7 call control signaling messages (e.g., ISUP and TCAP messages) are received and processed by the MGC, which in turn uses one or more non-SS7 signaling protocols (e.g., MGCP, UNI 4.0, ALTA, etc.) to communicate with an associated MG node.
In North America, ISUP messages and protocols are defined by Telcordia Technologies Specification of the Signaling System Number Seven, GR-246-CORE, Volume 3, T1.113.1-T1.113.5 (December 2001), the disclosure of which is incorporated herein by reference in its entirety. Likewise, in Europe, the International Telecommunications Union (ITU) Q.76x series of specifications defines the ISUP messages and protocols to be used by �international� signaling gateways. Within European non-gateway switching environments, the use of different ITU national ISUP variants is widespread. It will be appreciated that while this problem exists throughout the world, it is especially acute in Europe where practically each country employs its own ISUP variant.
The present invention includes a communications network element that is capable of providing intra- and inter-network message routing functionality in a networking environment having multiple signaling sub-networks where these different signaling sub-networks employ variations of a common or standard signaling protocol. In one scenario, the sub-networks correspond to different national signaling networks. A normalizing signaling gateway (NSG) routing node of the present invention receives a first signaling message that employs a first variant of a common or standard signaling protocol and subsequently creates a second �normalized� signaling message based on the first message. This normalized signaling message includes a normalized component and a variant component. The second signaling message may be routed to a call control node, such as a media gateway controller or softswitch. The call control node receives and processes the normalized signaling message. Because all messages received by the call control node are preferably converted to the normalized format, the call control node can serve multiple national networks regardless of the signaling protocol variants used in those national networks.
FIG. 3 is a network diagram illustrating a normalizing signaling gateway (NSG) routing node according to an embodiment of the present invention. In the example network implementation scenario shown in FIG. 3, an NSG routing node 300 is coupled to a British national signaling network 100 and a German national signaling network 101. British network 100 includes a pair of signaling points (SP) 102 and 104, as well as a media gateway node 112, while German network 101 includes a pair of signaling points (SP) 122 and 124, and a media gateway node 132. For the purposes of illustration, it is assumed that the British signaling network utilizes, for call setup and teardown, an SS7 ISDN user part (ISUP) variant described in PNO-ISC Specification Number 007�ISDN User Part, PNO-ISC/SPEC/007, Network Interoperability Consultative Committee, October 1997, the disclosure of which is incorporated herein by reference in its entirety. Likewise, it is assumed that German signaling network utilizes an SS7 ISDN user part (ISUP) variant described in ISDN User Part 3+, Section A: Formats and Codes (Germany), 28/15517-ANT21215 Uen, Ericsson, November 1992, the disclosure of which is incorporated herein by reference in its entirety.
The ITU national and international signaling protocols utilize 14-bit point codes. Accordingly, in one embodiment of an NSG routing node of the present invention, the ITU-N point code field 354 stores a 14-bit ITU-N compliant point code address and a 10-bit group code. This group code is a two character-ASCII code that is used to identify a particular country or national network or point code group. For instance, in the sample data shown in table 350, each ITU-N point code entry includes either a �DE� or a �UK� group code that is appended to the point code value, where �DE� indicates the German network, and �UK� indicates the British network. As such, two identical ITU-N point code values associated with two different networks may be simultaneously provisioned in routing table 350 provided these two ITU-N point code entries are assigned a different group code, which essentially defines the network within which each point code is valid. Group codes may be used in conjunction with ITU-N signaling messages to route messages to the appropriate point code group. However, such group codes may also be used in a similar manner with other signaling protocols (e.g., ANSI, ITU-I, etc.) to achieve this same duplicate point code routing capability. A more detailed discussion of group code based routing can be found in commonly-assigned, co-pending U.S. patent application Ser. No. 10/093,862 filed on Mar. 8, 2002, the disclosure of which is incorporated herein by reference in its entirety.
Referring to FIG. 7, linkset table 370 includes a compound key made of a linkset identifier 372 and a signaling link identifier 374. Linkset table 370 also includes IMT address and communication port fields 376 and 378 which contain IMT bus address and communication port information associated with communication modules connected to the IMT bus 312. More particularly, a record in the table 370 includes an IMT address and communication port value associated with a communication module that supports the specific link identified in the record key. For example, as shown in FIG. 7, link 0 of linkset 1 resides on a communication module that has an IMT bus address of 1305 and a communication port address of �A�. Link status field 380 indicates that link 0 of linkset 1 is available for service. Table 370 also includes an adjacent point code (APC) field 382, which contains information for identifying the signaling node connected to the distant end of a signaling link. In one embodiment, the APC field 382 includes ITU-N point code values and the group codes associated with each point code.
FIG. 12 illustrates an exemplary TALI packet format for carrying normalized signaling messages according to embodiments of the present invention. In the illustrated example, the TALI extended service (XSRV) packet is used. In FIG. 12, TALI XSRV packet 550 has several segments including a TALI header segment 560, an XSRV header segment 570, a common or part 1 data segment 590, and a variant or part 2 data segment 600. TALI header segment 560 includes an opcode parameter 562. XSRV header segment 570 includes an XSRV primitive parameter 572, one or more XSRV flags 574, a network type parameter 576, a group code parameter 578, and a PSTN presentation parameter 580. The common or part 1 data segment 590 includes a data type parameter 592, a data length parameter 594, and a data payload parameter 596. In one embodiment, a part 1 data type parameter value of �1� indicates that the associated part 1 data payload parameter 596 contains raw MTP3 data, while a part 1 data type parameter value of �2� indicates that the associated part 1 data payload parameter 596 contains normalized ISUP data. Likewise, the variant or part 2 data segment 600 includes a data type parameter 602, a data length parameter 604, and a data payload parameter 606. Again, in one embodiment, a part 2 data type parameter value of �3� indicates that the associated part 2 data payload parameter 606 contains ISUP variant data. Thus, in one case, the part 1 data segment of a TALI XSRV packet may contain a common or normalized component of ISUP data, while the part 2 data segment may contain a variant specific component of ISUP data.
Given the normalized TALI XSRV packet structure described above, it will be appreciated that normalized ISUP over TALI message includes 3 major parts: (1) a header containing fields that indicate how the content of the packet should be interpreted, (2) a common or normalized ISUP MSU section or segment (i.e., part 1 data segment) used to store ISUP MSU data that conforms to a standard or normalized ISUP MSU encoding specification (i.e., the data stored here is a normalized ISUP MSU that represents the best ETSI V3 ISUP packet that can be created from the original ISUP variant MSU), and (3) a variant specific data section or segment (i.e., part 2 data segment) that consists of zero or more instances of a data structure which contain variant specific information related to an ISUP parameter that was not �cleanly mapped� to an associated or related parameter in the normalized ISUP protocol.
With regard to opcode parameter 562 contained in the TALI header segment 560, an opcode value of �XSRV� is used to indicate an XSRV type TALI message. The XSRV primitive parameter 572 may contain a value of �XMTP� which indicates a raw message transfer part level 3 (MTP3) data payload format, or a value of �XNRM� which indicates a normalized ISUP payload format. A TALI XSRV-XMTP packet can be used to transport raw SS7 MTP3 message signaling unit (MSU) data beginning at the MTP3 service indicator octet (SIO) byte. As such, it should be noted that TALI XSRV-XMTP packets are not limited to transporting raw SS7 ISUP messages. These packets may also be used to transport raw transaction capabilities application part (TCAP) and mobile application part (MAP) MSU data. The benefit of such a header encoding technique over conventional ISUP MTP3 header encoding is that additional information about the type of signaling network, the ITU-National group (i.e., group code), and the format of the associated MTP3 data is also conveyed in the XSRV-XMTP packet header to assist the receiving node in determining how to decode and process the encapsulated MSU data.
The network type parameter 576 is present in both TALI XSRV-XMTP and XSRV-XNRM type packets to enable the recipient of a packet to effectively and efficiently interpret the MTP3 routing label of the MSU payload. The network type parameter is used to differentiate an ANSI MSU from an ITU-National MSU since the MTP3 SIO field specifies �National Network� for both of these MSU types, but the routing label has a different format in each MSU. In one embodiment of the present invention, the network type parameter may have one of three values: a �0� which indicates that the MTP3 routing label of the encapsulated SS7 ISUP MSU is in an ANSI/Bellcore format, a �1� which indicates that the MTP3 routing label of the encapsulated SS7 ISUP MSU is in an ITU-International format, or a �2� which indicates that the MTP3 routing label of the encapsulated SS7 ISUP MSU is in an ITU-National format.
In the event that particular parameter in an ISUP variant protocol does not map cleanly to the normalized ISUP protocol and consequently requires translation (i.e., translation indicator value is �Yes�), a parameter translation index or pointer table is consulted. A sample parameter translation index table 670 is presented in FIG. 16 and includes a PSTN presentation ID field 672, a parameter acronym field 674, a parameter field identifier 676, a parameter discrepancy description field 678, a translation rule identifier or pointer for a German to Normalized ISUP processing scenario 680, and a translation rule identifier or pointer for a Normalized to German ISUP processing scenario 682. Specific parameter translation rules or instructions are stored in a parameter translation rule table 690, as indicated in FIG. 17. Once again, the parameter translation rule table structure 690 depicted in FIG. 17 is presented primarily for the purposes of illustration. Practical implementation of a normalization rules table may include a potentially more complex data structure. In any event, the sample data table structure 690 shown in FIG. 17 contains a number of fields including a translation rule or scenario identifier 692, a message source field 694, a message destination field 696, a condition field 698, and a parameter translation rule field 700.
Beginning at LIM card 330 (FIG. 5), the SS7 signaling message is received (N1) and SS7 MTP Level 1 and 2 processing is performed on the incoming signaling message by the MTP Level 1 and 2 processes 332 and 334, respectively. Once again, MTP level 1 module 332 sends and receives digital data over a particular physical medium, while MTP level 2 module 334 performs error detection, error correction and ensures sequenced delivery of SS7 message packets. With MTP Level 1 and 2 processing complete, the signaling message packet is temporarily buffered in the I/O queue 336 before being passed up the stack to MTP Level 3 HMDC module 338. HMDC module 338 examines the signaling message packet and determines whether the packet requires processing by the NSG node 300. In one embodiment, HMDC process 338 may associate a 10-bit group code value (e.g., �DE�, �UK�, etc.) with the received signaling message based on the inbound signaling linkset or link.
Treatment or processing of the German ISUP variant MSU is determined based on the message normalization rules or scenarios defined in table 480 (steps N9 and N10). For example, as indicated in scenario �M-5A� shown in table 480, if the received German ISUP variant MSU is destined for an IP node that employs the normalized ISUP protocol, and the message type of the German ISUP MSU is not defined in the normalized protocol, then the German ISUP variant MSU is not normalized. Instead, the German ISUP variant MSU is transmitted to the destination node via a TALI XSRV-XNRM packet where part 1 of the packet carries raw MTP3 data from the ISUP variant MSU (steps N11 and N12).
In another possible normalization scenario such as �M-10A�, the contents of the received German ISUP variant MSU are to be normalized. In such a case, a message type may be common both the German and normalized ISUP protocols, but the parameters and/or parameter structures contained within that message type may differ between the two protocols. As such, it is necessary to segregate or sort the parameters contained within the German variant ISUP MSU into those that are common to the normalized ISUP protocol and those that are not common to the normalized ISUP protocol. With particular regard to those parameters that are determined to be common to the normalized ISUP protocol, conversion or translation of such message parameters may be required as a part of the normalization process.
In one embodiment, parameter translation indicator table 650 (FIG. 15) is accessed using the received German ISUP variant MSU message type and PSTN presentation to determine whether parameter specific translation is required (step N13). For example, as indicated by parameter structure field 664, German ISUP variant �Backward Call Indicator� parameter has a parameter structure that is not the same as the equivalent normalized ISUP �Backward Call Indicator� parameter. Consequently, parameter structure related translation of the �Backward Call Indicator� parameter may be required. As further indicated by parameter literal field 666, the German ISUP variant �Backward Call Indicator� parameter literal is not the same as the equivalent normalized ISUP �Backward Call Indicator� parameter literal. Consequently, parameter literal related translation of the German ISUP �Backward Call Indicator� parameter may also be required.
In the event that parameter translation processing is indicated, table 670 (FIG. 16) is next consulted to determine the relevant parameter translation scenario. In the case of variant ISUP-to-normalized ISUP processing, the German to normalized scenario field 680 returns a pointer to the appropriate translation rule entry or record in parameter translation rule table 690. Using the relevant data and translation rule information from tables 670 and 690, an ISUP message parameter requiring translation or conversion is processed. For example, as shown in parameter translation index table 670, the �Holding Indicator� field is reserved in the German ISUP variant protocol but is defined in the normalized protocol. Consequently, a pointer to the �P11-A� parameter translation scenario rule is associated with this parameter.
With regard to the �de-normalization� of normalized ISUP messages, it will be appreciated that such operations involve processing that is essentially the opposite or reverse of that described above. That is, the information contained in the common part 1 and variant part 2 data segments of a TALI XSRV packet is extracted, translated (if necessary), and re-assembled into a complete German ISUP variant MSU, which can then be routed to an SS7 node or destination.
An NSG routing node of the present invention receives signaling messages formatted according to a variant of a common or standard ISUP signaling protocol and subsequently create new �normalized� signaling messages based on the received ISUP variant message, and vice versa. The new normalized signaling messages include a normalized component and a variant component. The normalized component contains information that is common to all of the protocol variants that are being supported by the NSG node. Consequently, an IP node served by an NSG node of the present invention is required only to receive, interpret, and process a single signaling protocol (i.e., a normalized protocol), regardless of the number of different signaling protocol variants supported by the serving NSG node.
It will also be appreciated 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.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5377186 *Jul 21, 1993Dec 27, 1994Telefonaktiebolaget L M EricssonSystem for providing enhanced subscriber services using ISUP call-setup protocolUS5818919 *Jul 15, 1996Oct 6, 1998At&T Corp.Inter-network call forwarding with subscriber identityUS6724752 *Jul 6, 2000Apr 20, 2004Telefonaktiebolaget Lm Ericsson (Publ)IP telecommunicationsUS6741610 *Aug 16, 1999May 25, 2004Cisco Technology, Inc.Universal protocol conversionUS6842447 *Jun 14, 1999Jan 11, 2005Mci, Inc.Internet protocol transport of PSTN-to-PSTN telephony servicesUS6967956Jul 18, 2000Nov 22, 2005TekelecMethods and systems for providing message translation, accounting and routing service in a multi-protocol communications network environmentUS6990124 *Feb 8, 1999Jan 24, 2006Nortel Networks LimitedSS7-Internet gateway access signaling protocolUS7085279 *Dec 29, 2000Aug 1, 2006Cisco Technology, Inc.Method and apparatus for carrying telephony network traffic over an ATM networkWO2002021857A1Aug 2, 2001Mar 14, 2002Ericsson Telefon Ab L MCall looping prevention* Cited by examinerNon-Patent CitationsReference1Commonly-assigned, co-pending U.S. Appl. No. 09/658,522 for "Scalable Call Processing Node," (Unpublished, filed Sep. 8, 2000).Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7668183 *Feb 2, 2006Feb 23, 2010Alcatel-Lucent Usa Inc.Flexible SIP profile for mixed networksUS7801124Mar 18, 2005Sep 21, 2010TekelecMethods, systems, and computer program products for determining the application-level protocol of a signaling message* Cited by examinerClassifications U.S. Classification370/524, 370/467International ClassificationH04J3/12, H04Q3/00, H04L29/06Cooperative ClassificationH04L69/08, H04L69/18, H04L29/06, H04Q3/0025European ClassificationH04Q3/00D2, H04L29/06Legal EventsDateCodeEventDescriptionJan 3, 2012FPExpired due to failure to pay maintenance feeEffective date: 20111113Nov 13, 2011LAPSLapse for failure to pay maintenance feesJun 20, 2011REMIMaintenance fee reminder mailedAug 8, 2002ASAssignmentOwner name: TEKELEC, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SPRAGUE, DAVID MICHAEL;KANODE, MARK EDWARD;BRENDES, DAN ALAN;AND OTHERS;REEL/FRAME:013176/0475;SIGNING DATES FROM 20020606 TO 20020714RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services