Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR IMPROVING TCAP SIGNALING
Document Type and Number:
WIPO Patent Application WO/2007/112158
Kind Code:
A2
Abstract:
A method for improving Transaction Capabilities Application Part (TCAP) signaling is useful for improving the performance of communications networks that employ Signaling System 7 (SS7) protocols The method includes processing a TCAP message according to a modified format, where an Invoke ID parameter is positioned at a predetermined, fixed location in the TCAP message (step 430) Optionally, the method also includes processing a modified format identifier in the TCAP message, where the modified format identifier indicates that the Invoke ID parameter is positioned at a predetermined, fixed location in the TCAP message (step 425)

Inventors:
GE YUN-SHAN (CN)
Application Number:
PCT/US2007/062216
Publication Date:
October 04, 2007
Filing Date:
February 15, 2007
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
MOTOROLA INC (US)
GE YUN-SHAN (CN)
International Classes:
H04M7/00
Foreign References:
US20010018337A1
US20060013203A1
US20050130649A1
EP1515506A1
Attorney, Agent or Firm:
PACE, Lalita, W. et al. (1303 East Algonquin RoadSchaumburg, Illinois, US)
Download PDF:
Claims:

Claims

Wc Claim:

1. A method for improving Transaction Capabilities Application Part (TCAP) signaling in a communication network, the method comprising processing a TCAP message according to a modified format, where an Invoke ID parameter is positioned at a predetermined, fixed location in the TCAP message.

2. The method of claim 1 , further comprising processing a modified format identifier in the TCAP message, where the modified format identifier indicates that the Invoke ID parameter is positioned at a predetermined, fixed location in the TCAP message.

3. The method of claim 1, wherein processing the TCAP message according to the modified format comprises constructing the TCAP message by positioning the Invoke ID parameter at a predetermined, fixed location in the TCAP message.

4. The method of claim 1 , wherein processing the TCAP message according to the modified format comprises reading the Invoke ID parameter at a predetermined, fixed location in the TCAP message.

5. The method, of claim 2, wherein processing the modified format identifier in the TCAP message comprises constructing the TCAP message by positioning the modified format identifier at a predetermined, fixed location in the TCAP message.

6. The method of claim 2, wherein processing the modified format identifier in the TCAP message comprises reading the modified format identifier at a predetermined, fixed location in the TCAP message.

7. The method of claim 1 , wherein the predetermined, fixed location for the Invoke ID parameter is a last byte of the TCAP message.

8. The method of claim 2, wherein the modified format identifier is located in a header of the TCAP message.

9. The method of claim 2, wherein the modified format identifier is located after a Message Transfer Part (MTP) part of the TCAP message.

10. The method of claim 2, wherein the modified format identifier comprises two bits.

Description:

METHOD FOR IMPROVING TCAP SIGNALING

FIELD OF THE INVENTION

The present invention relates generally to routing data according to signaling system 7 (SS7) protocols. In particular, although not exclusively, the invention relates to a modified Transaction Capabilities Application Part (TCAP) signaling message format.

BACKGROUND OF THE INVENTION

Signaling System 7 (SS7) was developed in the 1980's by the International Telecommunications Union (ITU) as a protocol for establishing calls between public switched telephone network (PSTN) exchanges. SS7 is a form of common channel signaling (CCS) that concerns signaling components of call initiation, management, and termination, and operates independently of an actual call connection. That means that data concerning a phone call can be transmitted through a PSTN separately from the actual voice data of the call. Thus lower priority call signaling data does not interfere with higher priority voice data circuits.

SS7 is now used in both public wireless and wireline telephone networks, and provides a suite of protocols as well as an architecture that enable command and control of telephone networks. An SS7 network comprises signaling points (SPs) that are each defined by a unique point code (PC). A PC acts as an address that other SPs can use when sending and receiving SS7 messages. PCs are included in all messages

that are sent through an SS7 network, and identify both a sender and an intended receiver of a message.

An SS7 protocol stack conforms to the open systems interconnection (OSI) networking framework adopted by the International Standards Organization (ISO). Referring to FIG. 1, two tables juxtapose the seven OSI layers with four primary SS7 protocol layers. A description of the SS7 layers is provided below.

An SS7 message transfer protocol (MTP) level 1 comprises the first layer of an SS7 network. The MTP level 1 corresponds to an OSI physical layer, and is concerned with physical requirements such as hardware and clocking involved in transmission of SS7 messages. An MTP level 2 comprises the second layer of an SS7 network. The MTP level 2 corresponds to an OSI data link layer, and is concerned with link monitoring and network congestion, and message queuing in an SS7 network. Information managed at MTP level 2 comprise Message Signal Units (MSUs) that include data identifying a data type included in a packet. MSU data can include for example network management data, network testing data, or packet priority data. An MTP level 3 comprises the third layer of an SS7 network. The MTP level 3 corresponds to an OSI network layer, and is concerned with signaling message handling and signaling network management.

Finally, the integrated services digital network user part layer (ISUP) corresponds to the OSI application, presentation, session, transport and network layers. ISUP layer services are concerned with the basic process of setting up and tearing down a telephone call, and with managing messages that are needed to maintain or modify a call. A signaling connection control part (SCCP) layer complements the ISUP layer and involves signaling connections that ensure end-to-

end routing. It is the SCCP layer that uses the point codes (PCs) described above to transmit a message to a specified network node.

A Transaction Capabilities Application Part (TCAP) layer also complements the ISUP layer and concerns the packaging of data. The TCAP layer presents data that are routed through an SS7 network in various standardized formats, enabling different network environments to process and manage the data. For example, mobile application part (MAP) messages in Global System for Mobile Communications (GSM) networks are extensions of the TCAP layer.

SUMMARY OF THE INVENTION

According to one aspect, the present invention is a method for improving

Transaction Capabilities Application Part (TCAP) signaling in a communication network. The method includes processing a TCAP message according to a modified format, where an Invoke ID parameter is positioned at a predetermined, fixed location in the TCAP message. Optionally, the method also includes processing a modified format identifier in the TCAP message, where the modified format identifier indicates that the Invoke ID parameter is positioned at a predetermined, fixed location in the TCAP message.

Embodiments of the present invention therefore can reduce a level of system overhead resources needed to process TCAP messages. According to the present invention, TCAP messages can be processed faster and more efficiently, resulting in better tracking of Signaling system 7 (S S7) signaling messages. That in turn results in improved overall communications network performance and a higher level of Quality of Service for network subscribers.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the invention may be readily understood and put into practical effect, reference now will be made to exemplary embodiments as illustrated with reference to the accompanying figures, wherein like reference numbers refer to identical or functionally similar elements throughout the separate views. The figures together with a detailed description below, are incorporated in and form part of the specification, and serve to further illustrate the embodiments and explain various principles and advantages, in accordance with the present invention, where:

FIG. 1 includes two tables juxtaposing the seven Open Systems Interconnection (OSI) layers with the four primary Signaling System 7 (SS7) protocol layers;

FIG. 2 is a block diagram illustrating a conventional TCAP signaling message format;

FIG. 3 is a block diagram illustrating a modified TCAP signaling message format, according to an embodiment of the present invention;

FIG. 4 is a general flow diagram illustrating a method of constructing and transmitting a TCAP message in a system that uses both a modified TCAP signaling message format and a conventional TCAP signaling message format, according to an embodiment of the present invention; and FIG. 5 is a general flow diagram illustrating a method of receiving and reading a TCAP message in a system that uses both a modified TCAP signaling

message format and a conventional TCAP signaling message format, according to an embodiment of the present invention.

Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

DETAILED DESCRIPTION

Before describing in detail embodiments that are in accordance with the present invention, it should be observed that the embodiments reside primarily in combinations of method steps and apparatus components related to improving Transaction Capabilities Application Part (TCAP) signaling. Accordingly, the apparatus components and method steps have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention, so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

In this document, relational terms such as left and right, first and second, front and rear, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive

inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by "comprises a . . ." does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

According to conventional TCAP signaling, a number is assigned to each TCAP query and is used to identify a transaction. The same number is then copied into response messages so that queries and response messages can be correlated. TCAP coding employs a standard format that places particular types of data in particular components of a TCAP message. An invoke component describes a particular request and identifies a required action. A response component is used to return requested data. An error component is used when an answering database does not have enough information to respond to a query. Finally, a reject component is used when an answering database determines that it cannot comply with a query.

Referring to FIG. 2, a block diagram illustrates a conventional TCAP signaling message format 200. The message format 200 includes a Message Signaling Unit (MSU) header 205, a Message Transfer Protocol (MTP) part 210, spare bits 215, a Signaling Connection Control Part (SCCP) 220, a TCAP part 225, and an MSU tail 230. Flags are used in the TCAP part 225 to identify the various message components described above. For example, before an error component is included in a TCAP part 225, a flag will be set to announce the error component. A

subsequent field will then describe how long an included error code is. Finally another field will identify a cause of the error.

The conventional TCAP message format described above is still used in Mobile Application Part (MAP) messages in recent 3 G Wideband Code Division Multiple Access (WCDMA) wireless communications systems. Such systems however include a plethora of new services such as multi-rate voice calls, video calls, and various supplementary services. Further, the number of subscribers to 3G WCDMA systems is increasing rapidly. Therefore the relative volume of MAP signaling messages in 3 G WCDMA systems has increased considerably over previous 2G Global System for Mobile Communications (GSM) systems. If the volume of MAP messages exceeds the capacity of a system, higher priority data will push aside the MAP messages, preventing the MAP messages from performing their designated functions.

Referring to FIG. 3, a block diagram illustrates a modified TCAP signaling message format 300, according to an embodiment of the present invention. Similar to the conventional TCAP signaling message format 200, the message format 300 includes an MSU header 305, an MTP part 310, spare bits 315, an SCCP part 320, and a TCAP part 325. However, unlike the conventional message format 200, the message format 300, according to one embodiment of the present invention, includes an optional Invoke ID parameter 330 positioned at a predetermined, fixed location in a message. According to the message format 300, the optional Invoke ID parameter 330 is positioned at a last byte of a TCAP message. An MSU tail 335 then follows the optional Tnvoke TD parameter 330.

According to an embodiment of the present invention, the Invoke ID parameter 330 can significantly improve the processing efficiency of TCAP messages in 3G wireless communication systems. That is because, according to existing Third Generation Partnership Program (3GPP) specifications, a conventional Invoke ID parameter — which identifies an owner of a MAP message and is thus used in tracking MAP messages — is not anchored at a predetermined, fixed location in the conventional TCAP message format 200. Instead, various optional content can be inserted into a conventional TCAP message before a conventional Invoke ID parameter. That means that a station that receives a conventional TCAP message must search the entire message, bit by bit, in order to locate a conventional Invoke ID parameter. Further, the conventional Invoke ID parameter must be located by each network station that receives a TCAP message, so that each station can determine whether it needs to take any action based on the message. Thus searching such conventional TCAP messages can consume substantial time and processor resources of a 3 G system.

According to an embodiment of the present invention, the optional Invoke ID parameter 330 is positioned at a predetermined, fixed location relative to the MSU header 305. That means that when a TCAP message using the modified TCAP message format 300 is received, a tracking system does not need to search the entire message bit by bit in order to locate the optional Invoke ID parameter 330. Rather, the tracking system can immediately identify the predetermined, fixed location and read the optional Invoke ID parameter 330. Considering that millions of TCAP messages are processed by 3G WCDMA systems, the present invention can thus save considerable system resources.

Using an additional feature of the present invention, messages that are formatted according to the modified TCAP signaling message format 300, can operate together with messages that are formatted according to the conventional TCAP signaling message format 200. The additional feature is a modified format identifier that indicates that the Invoke ID parameter is positioned at a predetermined, fixed location in a TCAP message. The modified format identifier also can be positioned at a predetermined, fixed location in a TCAP message. According to one embodiment of the present invention, the spare bits 315 are employed to store such a modified format identifier.

For example, when a station receives a modified TCAP signaling message format 300 in a system that uses both the modified TCAP signaling message format 300 and the conventional TCAP signaling message format 200, the station initially will not recognize which format is employed in a received TCAP message. However if the spare bits 315 include a modified format identifier, such as the digits "01", that indicates that the station does not need to search the entire TCAP message for an Invoke ID parameter; rather, the station can read the Invoke ID parameter immediately at the predetermined, fixed location in the TCAP message.

According to various embodiments of the present invention, a predetermined, fixed location of the optional Invoke ID parameter 330 can be anywhere in a TCAP message. As long as the location is anchored to some component of the modified TCAP signaling message format 300, such as the MSU header 305, a station that receives a TCAP message according to the modified format 300 will be able to

immediately locate and read the optional Invoke ID parameter 330, without having to search the entire TCAP message.

Example. Below is an example of a TCAP message constructed according to the modified signaling message format 300, according to an embodiment of the present invention:

I BITMASK HD Name I Comment or Value

15:30:59 PM, 254,233 MSC-HLR 273 1365 MTP-L2 MSU SCCP UDT MAP BEG I

|MTP Level 2 (MTP-L2) MSU (= Message Signal Unit) I Message Signal Unit

1-1001010 iBackward Sequence Number I 74

|1 I Backward Indicator Bit |1

1-1010000 I Forward Sequence Number I 80

|1 I Forward Indicator Bit |1 I —111111 I Length Indicator I 63

I 01 lmodified format identifier I

I 0011 I Service Indicator I SCCP

I --00 I Sub-Service: Priority

I Spare/priority 0 (U.S.A. only) | 110 I Sub-Service : Network Ind | National message

|**bl4*** I Destination Point Code 11365

|**bl4*** lOriginating Point Code 1273

HTU-T White Book SCCP (SCCP) UDT (= Unitdata) IUnitdata 10101 I Signalling Link Selection I 5 100001001 ISCCP Message Type I 9

I 0001 lProtocol Class IClass 1

11000 lMessage Handling | Return message on error

100000011 I Pointer to parameter I 3

100010000 I Pointer to parameter 116 100011010 I Pointer to parameter 126

I Called address parameter 100001101 I Parameter Length 113

I 0 I Point Code Indicator I PC absent

I ]__ l Subsystem No. Indicator ISSN present I —0100— I Global Title Indicat | Has transln, n-plan, code, natur

|-1 I Routing Indicator | Route on DPC 4- Subsystem No.

|0 I For national use |0

100000110 I Subsystem number I HLR

100000000 [Translation Type I Not used I 0001 lEncoding Scheme |BCD, odd number of digits

10111 INumbering Plan | ISDN/Mobile (Rec. E.214)

1-0000100 INat. of Address Indicator | International number

10 I Spare |0

|**b60*** I Called Address Signals |" 861391234567203 s

0000 I Filler |0

Calling address parameter

00001010 I Parameter Length I 10 0 I Point Code Indicator I PC absent _* ] _ I Subsystem No. Indicator | SSN present

—0100— I Global Title IndicatolHas transln, n-plan, code, natur

-0 I Routing Indicator | Route on Global Title

0 I For national use |0

00000111 I Subsystem number |VLR 00000000 I Translation Type I Not used 0010 I Encoding Scheme | BCD, even number of digits

0001 I Numbering Plan

ISDN/Telephony (E .164/E.163) |

-0000100 I Nat. of Address Indicator

International number |

0 I Spare 10

***B5*** I Calling Address Signals 8613900776-

Data parameter

01010000 [Parameter length |80 **B80*** I Data 162 4e 48 04 5c 01 04 dc 6b Ia 28...

E-GSM 09.02 (MAP) Version 5, 3.0 (MAP) BEG (= Begin) Begin

01100010 |Tag (APPL [2] ) 01001110 lLength 178

1 Origination Transaction ID 01001000 ITag (APPL P [8] )

00000100 ILength 14 ***B4*** lOrig Trans ID 11543570652

2 Dialogue Portion 101101011 |Tag (APPL C [H] ) 100011010 ILength |26 |2.1 Dialogue External 100101000 |Tag I (UNIV C External) 100011000 ILength I 24

12.1.1 Dialogue Object ID

100000110 |Tag (UNIV P Obj Identifier)

100000111 ILength 17

100000000 IAuthority I CCITT Recommendation 100010001 IName Form Iq 110000110 lRec Number 17 100000101 |Rec Number |73

100000001 I AS Il 100000001 |Dialog-AS I Dialogue PDU 100000001 lVersion Il

12.1.2 Dialogue single ASNl

110100000 ITag (CONT C :o] 100001101 ILength |13 12.1.2.1 Dialogue Request 101100000 |Tag (APPL C :o] ) 100001011 ILength 111

12.1.2.1.1 Application Context Name

110100001 ITag (CONT C [1] )

1 00001001 I Length 1 2 . 1 . 2 . 1 . 1 . 1 ACN Obj ect ID

100000110 |Tag I (UNIV P Obj Identifier)

100000111 ILength 17 10000 lObjId ICCITT

I 0100 I Organization I Identified-organization

100000000 I IETSI

100000000 I Domain IMobile Domain

100000001 IMobile Subdomain I GSM-Network

100000000 I Common Component ID IAC-ID

100000001 I Application Context I Network Loc Upd 100000011 lVersion I - unknown / undefined -

I 3 Component Portion

101101100 |Tag I (APPL C [12] ) 100101010 ILength I 42 |3.1 Invoke 110100001 |Tag I (CONT C [1] ) 100101000 ILength |40

13.1.1 Invoke ID 100000010 lTag I (UNIV P Integer) 100000001 ILength U

101101101 I Invoke ID value |109

13.1.2 Local Operation 100000010 |Tag I (UNIV P Integer) 100000001 ILength U 100000010 lOperation Code I Update Location |3.1.3 Parameter Sequence 100110000 |Tag I (UNIV C Sequence (of) ) 100100000 ILength 132

13.1.3.1 Imsi 100000100 |Tag I (UNIV P OctetString) 100001000 ILength |**b60*** IMCC + MNC + MSIN I -789011234567203"

11111 IFILLER 115

13.1.3.2 Msc Number 110000001 |Tag I (CONT P [1] ) 100000110 ILength 16

|1 I Extension Indicator I No Extension

1-001 INature of Address I International number

I 0001 INumbering Plan Indicator I ISDN Telephony No plan

(E.164)

|*** B 5*** | MSC Address Signals

I "8613900776-

13.1.3.3 VIr Number 100000100 lTag I (UNIV P OctetString)

100000110 I Length 16 U I Extension Indicator INo Extension

1-001 INature of Address I International number

I 0001 INumbering Plan Indicator ISDN Telephony No plan

(E.164)

|VLR Address Signals I -8613900776-

3.1.3.4 Ellipsis

***B6*** lEllipsis Octets | a6 04 80 02 06 cO

01101101 I Invoke ID value (located at last byte) 1109

Referring to FIG. 4, a general flow diagram illustrates a method 400 of constructing and transmitting a TCAP message in a system that uses both the modified TCAP signaling message format 300 and the conventional TCAP signaling message format 200, according to an embodiment of the present invention. At step 405 it is determined whether the modified TCAP signaling message format 300 should be used. If not, then at step 410 a conventional TCAP message is constructed, and at step 415 the conventional message is transmitted. However, if at step 405 it is determined that the modified TCAP signaling message format 300 should be used, then at step 420 a modified TCAP message is constructed. At step 425, a modified format identifier is added, such as by adding the digits "01" to the spare bits 315. At step 430 the optional Invoke ID parameter is added at a predetermined, fixed location in the TCAP message, such as at the last byte of the message. The TCAP message is then sent at step 415.

Referring to FIG. 5, a general flow diagram illustrates a method 500 of receiving and reading a TCAP message in a system that uses both the modified TCAP signaling message format 300 and the conventional TCAP signaling message format 200, according to an embodiment of the present invention. After a message is received by a station, at step 505 it is determined whether a modified format identifier is included in the message. For example, the station will read the spare bits 215, 315 to determine whether the digits "01" appear. If not, then at step 510 the station will know that the conventional TCAP signaling message format 200 is used and will

therefore search the entire message for the Invoke ID parameter. At step 515, the Invoke ID parameter is then read and the message is processed accordingly. However, if at step 505 it is determined that a modified format identifier is included in the message, then at step 520 the station locates the optional Invoke ID parameter 330 at the predetermined, fixed location in the message. At step 515, the Invoke ID parameter is then read and the message is processed accordingly.

Advantages of the present invention therefore include reducing a level of system overhead resources needed to process TCAP messages. According to the present invention, TCAP messages can be processed faster and more efficiently, resulting in better tracking of SS7 signaling messages. That in turn results in improved overall communications network performance and a higher level of Quality of Service for network subscribers.

The above detailed description provides an exemplary embodiment only, and is not intended to limit the scope, applicability, or configuration of the present invention. Rather, the detailed description of the exemplary embodiment provides those skilled in the art with an enabling description for implementing the exemplary embodiment of the invention. It should be understood that various changes can be made in the function and arrangement of elements and steps without departing from the spirit and scope of the invention as set forth in the appended claims. It will be appreciated that embodiments of the invention described herein may be comprised of one or more conventional processors and unique stored program instructions that control the one or more processors to implement, in conjunction with certain non- processor circuits, some, most, or all of the functions of improving TCAP signaling as

described herein. The non-processor circuits may include, but are not limited to, a radio receiver, a radio transmitter, signal drivers, clock circuits, power source circuits, and user input devices. As such, these functions may be interpreted as steps of a method for improving TCAP signaling. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used. Thus, methods and means for these functions have been described herein. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

In the foregoing specification, specific embodiments of the present invention have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention. The benefits, advantages, solutions to problems, and any elements that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of any or all of the claims. The invention is defined solely by the appended claims including

any amendments made during the pendency of this application and all equivalents of

those claims.