WO2000067492A1

WO2000067492A1 - Transaction capabilities application part (tcap) transaction termination method

Info

Publication number: WO2000067492A1
Application number: PCT/SE2000/000694
Authority: WO
Inventors: Elsa Delgado
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 1999-05-03
Filing date: 2000-04-11
Publication date: 2000-11-09
Also published as: AU4787800A; MXPA01011084A; CA2373206A1; JP2002543718A; BR0010258A

Abstract

In a wireless intelligent network comprising a first node (10), a second node (20), and a third node (30) engaged in a Transaction Capability Application Part (TCAP) communication transaction, wherein the first and third nodes (10 and 30) experience an unexpected network communication failure, a method supporting transaction closure without creating conversation permission errors comprises the steps of opening a TCAP transaction by sending a first message (40) from the first node (10) to the second node (20); sending a second message (50) in response to the first message (40) from the second node (20) to the first node (10) requesting the initiation of communication between the first node (10) and the third node (30); establishing communication between the first and third nodes (10 and 30); experiencing a failure (70) in the established communication; sending a third message (100) having a package type of 'conversation with permission' in response to the experienced failure from the first node (10) to the second node (20); and closing the TCAP transaction by sending a fourth message (110) from the second node (20) to the first node (10).

Description

TRANSACTION CAPABILITIES APPLICATION PART (TCAP) TRANSACTION TERMINATION METHOD

CROSS REFERENCE TO RELATED APPLICATION

Reference is made to U.S. Patent Serial No. 09/088,984, filed on June 2, 1998, which is incorporated herein m its entirety.

BACKGROUND OF THE INVENTION Technical Field of the Invention

The present invention relates generally to communications systems and, in particular, to the specification of Transaction Capability Application Part (TCAP) package types for wireless network messages . Description of Related Art Reference is now made to FIGURE 1 wherein there is shown a signal flow and nodal operation diagram illustrating prior art messaging between nodes in a wireless intelligent network. For example, the message flow may be exemplified by American National Standards Institute (ANSI-41) message communication protocol, wherein the TCAP transaction identifier is shared, using ANSI-41 Invoke messages. The ANSI-41 standard, Revision D, is incorporated herein by reference m its entirety. A Wireless Intelligent Network (WIN) 9 provides mobile telecommunications subscribers with access to many enhanced network functions and services, for example, voice storage, FAX storage, and voice recognition. These functions are typically provided by an external specialized resource, or Intelligent Peripheral (IP) 30. However, for various reasons, communication failures may occur between the Mobile Switching Center (MSC) 10 and the IP which, because of the specified TCAP message package types results, in transactions which are never completed.

The problem of incomplete TCAP transactions is illustrated by the telecommunications network 9, which includes a MSC 10, a Service Control Function (SCF) 20, and an IP 30. To connect the IP 30 to the MSC 10, a message must be received by the SCF 20 to prompt the issuance of a ConnectResource message, such as an OrigmationRequest LocationRequest, TransferBusy, or TransferNoAnswer message. In the case of Fig. 1, the Origination Request Invoke message 40 is sent from the MSC 10 to the SCF 20 associated with the origination trigger. After the Origination Request Invoke message 40 is receiveα and processed by the SCF 20, a ConnectResource Invoke message 50 is sent from the SCF 20 to the MSC 10, requesting a connection to be set up between the MSC 10 and the IP 30.

In response to the ConnectResource Invoke message 50, the MSC 10 routes the incoming call to the IP 30 during call setup 60. Various events may then take place between the subscriber serviced by the MSC 10, and the IP 30. However, due to electromagnetic interference, physical line problems, or other disturbances, the connection established between the IP 30 and the MSC 10 (and thus, the subscriber) may fail unexpectedly. This occurs at the failure point 70. A Connection Failure Report Invoke (having a package type of conversation without permission) message 80 is then sent from the MSC 10 to inform the SCF 20 of the type and cause of the failure 70. However, since the message 80 is sent with a package type of 'conversation without permission," any type of response presented to the MSC 10 will result in an error. For example, the origination request response message 90, sent by the SCF 20 to the MSC 10, is not received by the MSC 10 because the message 80 was sent with a package type of 'conversation without permission." As noted above, the Connection Failure Report Invoκe message 80 is included as part of the same TCAP transaction initiated by other ANSI-41 messages, of wnich the Origination Request Invoke message 40 is but one. The specification for the TCAP package type is defined m the WIN PN-3661 standard incorporated by reference herein m its entirety as a supplement to the ANSI-41 standard.

Since the origination request response message 90 is not processed by the MSC 10, the result is that the SCF 20 is unable to instruct the MSC 10 to disconnect the call. Not only is such a result inconvenient to the mobile subscriber, but it wastes valuable network resources by maintaining a connection which fails to benefit from use of the IP 30. Some type of termination activity, such as a time out, may eventually result at the direction of the MSC 10, but this does not occur as a result of information being received from the SCF 20 regarding the failed connection to the IP 30. In addition, other problems may arise as a result of failing to properly close the TCAP transaction. For example, the system may be unable to redirect the call to a voice mail system.

In general, there is a need to provide a method for graceful termination of TCAP transactions where networx communication failures occur between a MSC and an IP wnen a Connection Failure Report Invoke message is sent from the MSC to the SCF originally requesting the connection between the MSC and the IP. Even more generally, there is a need for a method to provide graceful TCAP transaction termination where several nodes are interconnected in a wireless intelligent network, and two of the nodes experience an unexpected network communication failure. This method should address the failure of the ANSI-41 and PN-3661 standards to provide conversation with permission as a package type for certain messages, such as the connection failure report invoke message, which prevents such graceful termination.

SUMMARY OF THE INVENTION The present invention solves the foregoing problem concerning graceful closure of TCAP transactions, even when unexpected IP communication failures occur. The problem is eliminated by modifying the package type specified for certain ANSI-41 and PN-3662 messages to include 'conversation with permission." Such a package type enables the reception and processing of response messages by the node originating the message with the modified package type. The node receiving the message having the modified package type is accordingly given permission to generate an appropriate response message, which enables the graceful closure of the TCAP transaction. The messages having a modified package type include ANSI-41 and PN-3662 Invoke messages, such as the Connection Failure Report Invoke message.

More specifically, in a first implementation of the method, wherein a WIN comprises a first node, a second node, and a third node engaged m a TCAP transaction, and the first and third nodes experience an unexpected network communication failure, the method which supports closing the transaction without creating conversation permission errors comprises the steps of opening a TCAP transaction with a first message sent from the first node to the second node, sending a second message requesting the first node to initiate communication between the first node and the third node, m response to the first message; establishing communication between the first and third nodes; experiencing a communication failure between the first and third nodes; sending a third message having a package type of 'conversation with permission" from the first to the seconα node in response to the failure; and closing the TCAP transaction without conversation permission errors by sending a fourth message from the seconα noαe to the tmrα node m response to the first message .

The first node may be a mobile switching center. The seconα node may be selected from a service control point, a home location register, or a service node. The thirα node may oe any of several intelligent peripherals, such as one that allows the network to implement voice recognition, FAX message storage, or voice message storage. The first, seconα, and thirα messages are typically ANSI-41 Invoke messages. For example, the third message may be a Connectιon_Faιlure_Report Invoke message, and the S/R throughout with underscore connection fourth message may be an origination request response. Further, the first message may be an Origination Request Invoke message, and the second message may be a Connect Resource Invoke message. The first, second and third messages may also be characterized as non-answer messages, since they are not sent to the MSC as a 'response" to the original request by the MSC.

BRIEF DESCRIPTION OF THE DRAWINGS A more complete understanding of the method and apparatus of the present invention may be acquired by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings wherein:

FIGURE 1, previously described, is a signal flow and nodal operation diagram illustrating a failed TCAP transaction using ANSI-41 messaging in the prior art;

FIGURE 2 is a signal flow and nodal operation diagram illustrating the method of the present invention wherein a TCAP transaction is properly terminated m response to a network communication failure; and

FIGURE 3 is a signal flow and nodal operation diagram illustrating the method of the present invention aαapted to communication with a Service Control Point.

DETAILED DESCRIPTION Reference is new made to Fig. 2, which illustrates a signal flow and nodal operation diagram for the method of the present invention. In this illustration, the Connection Failure Report Invoke message has been assigned a TCAP package type of 'conversation with permission," and therefore, the transaction may be terminated gracefully (i.e., without incurring conversation permission errors) .

As shown, the MSC 10 communicates with the SCF 20 and the IP 30 within the telecommunications network 9, at least up until tr.e failure point 70. That is, an Origination Request Invoke message (first message) 40 is sent from the MSC 10 to the SCF 20, which is received and processed, and prompts the SCF 20 to send a Connect Resource Invoke message (second message) 50 from the SCF 20 to the MSC 10 so as to request the MSC 10 to connect to the IP 30. The call is set up at step 60, and communication between the MSC 10 and the IP 30 occurs until the unexpected failure point 70.

In the method of the present invention, a TCAP package type of 'conversation with permission" is specified for the Connection Failure Report Invoke message (third message) 100, instead of the package type identifier of 'conversation without permission" in the message 80 of Fig. 1. In this scenario, the specified package type identifier of 'conversation with permission" for the Connection Failure Report Invoke message 100 permits continued processing of the TCAP transaction and allows the origination request response message (fourth message) 110 to be processed by the MSC 10. No conversation permission error occurs m this scenario because the Connection Failure Report Invoke message 100 was sent using the package type of 'conversation with Dermission." Reference s now made to Fig. 3, wherein is shown a signal flow and noαal operation diagram illustrating the present invention as it may be applied to the scenario wnere an MSC 10 communicates with a Service Control Point (SCP) 120, and, after connection has been successfully established to an IP 30, the connection unexpectedly fails. The scenario would also apply to the application of the invented method to the unexpected failure of a connection to a Service Node (SN) . The illustration is for exemplary purposes only, and should be readily apparent to those skilled m the art that the MSC 10, SCP 120, IP 30, and SCF 20 can all be represented as generic nodes in a WIN 9. For example, the MSC 10 may oe considered as a first node, the SCF 20 and SCP 120 (or, alternatively, a Home Location Register) can be considered as a second node, and the IP 30 may be considered as a third node. The IP 30 may be used to implement voice recognition within the network 9, or the IP 30 may be used to implement FAX message storage, voice message storage, etc. within the network 9.

In Fig. 3, the TCAP transaction involves an Origination Request transaction between the MSC 10 and the SCP 120. Of course, those skilled in the art will recognize that similar information flow appears m the context of other operations which involves an MSC 10 and a service logic Network Entity (NE) . For example, the operation may include an Analyzedlnformation message between the MSC 10 and the SCP 120, or for originations or terminations, it may occur within the context of a ServiceRequest between two network nodes.

In this particular scenario the serving MSC 10 sends an Origination Request message 130 to the SCP 120 associated with tne originating trigger, based on the Mobile Identification Number (MIN) , Mobile Directory Number (MDN) , and TriggerType (TT) . The SCP 120 then determines that an IP 30 is required to identify the calling party, and sends a Seize Resource message 140 which specifies the SRFCapability (i.e., the specialized resource capabilities requested, including the type of standard specialized resource requested and the type of private specialized resource requested) , and the Preferred Language Indicator (PLIND), which designates the preferred language for identification. The Seize Resource message 140 is sent to the speaker- dependent IP 30 associated with the calling party, requesting the necessary resource.

In response to the Seize Resource message 140, the IP 30 allocates a Temporary Local Directory Number (TLDN) , which is returned to the SCP 120 in the seize resource response message 150, for access to the appropriate special resource. The SCP 120 is then able to forward the IP 30 TLDN to the serving MSC 10 in a ConnectResource message 160, which also contains the carrier digits (CARDGTS), if applicable, and special routing instructions (ROUTDGTS), if applicable. At this time, the SCP 120 sets the WIN Response Timer

(WINRT) to wait for the Instruction Request message from the IP 30. The Reset Timer (REST) is set to expire before the MSC 10 Service Switching Function

Timer (SSFT) . If the WINRT does expire, a ResetTimer message will be sent to the MSC 10 to initialize and restart the SSFT timer.

The MSC 10 routes the calling party call to the IP 30 using the specified TLDN at call setup step 60. When the call is received, the IP 30 sends an InstructionRequest message to the SCP 120 to request instructions for operation. At this time, the communication between the calling party and the IP 30 is established and continues in the normal fashion. However, at some point, the MSC 10 determines that the connection between the calling party and IP 30 has unexpectedly failed at failure point 70. The failure point 70 may occur any time after the call setup 60 is complete, cut in this particular scenario it may be assumed to occur almost immediately after the MSC 10 connection to the IP 30 has been established. Several types of failure are possible; the illustrated scenario assumes that the communication with the IP 30 has been disrupted, but the calling party has not been disconnected.

After detecting a failure in the IP 30 connection, the MSC 10 stops the SSFT timer and sends a ConnectionFailureReport Invoke message 180 to the SCP 120, including the Failure Type (FAILTYPE) and Failure Cause (FAILCAUSE) . In this case, the Failure Type is a 'resource disconnect" and the Failure Cause is received from the ISDN User Part the SCP 120 m this scenario receives the connection failure report invoke message 180 before an SRF Directive (SRFDIR) message has been sent to the IP 30. Therefore, the SCP 120 sends the IP 30 an InstructionRequest response message 190 without sending the IP 30 a SRFDIR message. Depending on the specific service logic program executing at the SCP 120, any of several actions may be undertaken. For example, the SCP 120 may select the same IP 30 for sending another Seize Resource message, attempting to re-establish calling party-network interaction. Alternatively, the SCP 120 may select an alternative IP 30 for attempts re-establish user- network interaction. In the scenario illustrated in Fig. 3, the SCP 120 sends an Origination Request Response message that includes an Action Code (ACTCODE) parameter instructing the MSC 10 to disconnect the call. In any event, the TCAP transaction is closed gracefully, and processing of the origination request response message 200 is allowed by the MSC 10 since the connection Failure Report Invoke message 180 is specified to have a TCAP package type 'conversation with permission." It should be noted that the Origination Request message 130, the Connect Resource message 160, and the Connection Failure Report message 180 can all be characterized as non-answer messages which are not sent in response to any particular query by a node m the WIN 9. These messages 130, 160, and 180 are also illustrated in Fig. 3 as TCAP Invoke messages, but this is not a specific requirement for implementation of the method of the present invention. While specific examples of operation of the present invention relating to Origination Request ANSI- 41 messages have been disclosed, it should be understood that similar package type modifications supporting TCAP transaction closure may be made to other ANSI-41 messages including, for example, Location Request, Feature Request, Transfer to Number Requests, Analyzed Information, Facility Selected and Available, Service Request, Transfer Busy, and Transfer No Answer. Although preferred embodiments of the method of the present invention have been illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood by those skilled in the art that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications, substitutions without departing from the spirit of the invention as set forth and defined m the following claims.

Claims

WHAT IS CLAIMED IS: 1. In a wireless intelligent network comprising a first node, a seconα node, and a third node engaged m a Transaction Capability Application Part (TCAP) transaction, wherein the first and third nodes experience an unexpecteα network communication failure, a method which supports closing the transaction without creating conversation permission errors comprises the steps of: opening a TCAP transaction by sending a first message from the first node to the second node; sending a second message from the second node to the first node, in response to the first message, wherein the second message requests the first node to initiate communication between the first node and the third node; establishing a communication between the first node and the third node in response to the second message; experiencing at the first node a failure in the communication established between the first and third nodes; sending a third message from the first node to the second node m response to the failure in communication between the first and third nodes, the third message having a package type of 'conversation with permission" ; and closing the TCAP transaction without creating conversation permission errors by sending a fourth message from the second node to the first node in response to the first message.

2. The method of Claim 1, wherein the first node comprises a mobile switching center, the second node comprises a service control function, and the third node comprises an intelligent peripheral.

3. The methoα of Claim 1, wherein the third message _s a Connection Failure Report Invoκe Message and the fourth message is an origination request response.

4. The method of Claim 1, wherein the first message is an INVOKE message.

5. The method of Claim 1, wherein the first, second, and third messages are INVOKE messages.

6. The method of Claim 1, wherein the second node is a selected one of a Service Node (SN) , a Home Location Register (HLR) , or a Service Control Point (SCP) .

7. The method of Claim 1, wherein the third node is used to implement voice recognition within the network.

8. The method of Claim 1, wherein the third node is used to implement fax message storage within the network.

9. The method of Claim 1, wherein the tnird node is used to implement voice message storage within the network.

10. In a wireless intelligent network comprising a first node, a second node, and a third node engaged in a Transaction Capability Application Part (TCAP) transaction, wherein the first and third nodes experience an unexpected network communication failure, a method which supports closing the transaction without creating conversation permission errors comprises the steps of: opening a TCAP transaction by sending a first non-answer message from the first node to the second node; receiving the first non-answer message at the second node and sending a second non-answer message from the second node to the first node, wherein the second non-answer message requests the first node to initiate communication between the first node and the third node; establishing a communication between the first node and the third node in response to the second non-answer message; experiencing at the first node a failure in the communication established between the first and third nodes; sending a third non-answer message from the first node to the second node in response to the failure in communication between the first and third nodes, the third non-answer message having a package type of 'conversation with permission"; and closing the TCAP transaction without creating conversation permission errors by sending a fourth message from the second node to the first node in response to the first message.

11. The method of Claim 10, wherein the first node comprises a mobile switching center, the second node comprises a service control function, and the third node comprises an intelligent peripheral.

12. The method of Claim 10, wherein the third non-answer message is a Connection Failure Report Invoke Message and the fourth message is an origination request response.

13. The method of Claim 10, wherein the first non-answer message is an INVOKE message.

14. The method of Claim 10, wherein the first, second, and third non-answer messages are INVOKE messages.

15. The method of Claim 10, wherein the second node is a selected one of a Service Node (SN) , a Home Location Register (HLR) , or a Service Control Point (SCP) .

16. The method of Claim 10, wherein the third node is used to implement voice recognition within the network.

17. The method of Claim 10, wherein the third node is used to implement fax message storage within the network.

18. The method of Claim 10, wherein the third node is used to implement voice message storage within the network.

19. In a wireless intelligent network comprising a Mobile Switching Center (MSC) , a Service Control Function (SCF), and an Intelligent Peripheral (IP) engaged in a Transaction Capability Application Part (TCAP) transaction, wherein the MSC and the IP experience an unexpected network communication failure, a method which supports closing the transaction without creating conversation permission errors comprises the steps of: opening a TCAP transaction by sending an Origination Request Invoke message from the MSC to the SCF; sending a Connect Resource Invoke message from the SCF to the MSC, in response to the Origination Request Invoke message, wherein the Connect Resource Invoke message requests the first node to initiate communication between the first node and the IP; establishing a communication between the MSC and the IP in response to the Connect Resource Invoke message; experiencing at the MSC a failure in the communication established between the MSC and the IP; sending a Connection Failure Report Invoke message from the MSC to the SCF in response to the failure in communication between the MSC and the IP, the Connection Failure Report Invoke message having a package type of 'conversation with permission"; and closing the TCAP transaction without creating conversation permission errors by sending an origination request response message from the SCF to the MSC in response to the Origination Request Invoke message.

20. The method of Claim 19, wherein the SCF is a Service Control Point (SCP) .