MXPA01011084A - Transaction capabilities application part (tcap) transaction termination method. - Google Patents

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

METHOD OF TERMINATION DBARANSACTION OF THE PART OF APPLICATION OF TRANSACTION CAPACITIES (TCAP) CROSS REFERENCE TO THE RELATED APPLICATION Reference is made to US Pat. No.

Series 09 / 088,984, filed on June 2, 1998, which is hereby incorporated in its entirety.

BACKGROUND OF THE INVENTION Technical Field of the Invention The present invention relates generally to communication systems and, in particular, to the specification of packet types of the Transaction Capability Application Part (TCAP) for wireless network messages.

Description of Related Art Reference is now made to FIGURE 1 wherein a nodal operation and signal flow diagram illustrating prior art messaging between nodes in a wireless intelligent network is shown. For example, the message flow can be exemplified by the message communication protocol of the American National Standard Institute (ANSI-41), where the TCAP transaction identifier is shared, using messages that invoke ANSI-41.

'LÍÍ.? ±, A > A?, ^ A a »a¡Éafafc«. «T ** h * - i ** * .. A» The ANSI-41 standard, revision D, is incorporated herein by reference in its entirety. A Smart Wireless Network 9 (WIN) provides mobile telecommunications subscribers with access to many enhanced network functions and service, for example, voice storage, FAX storage, and voice recognition. These functions are typically provided by an external specialized resource, or Smart Peripheral (IP). However, for various reasons, communication failures may occur between the Mobile Switching Center (MSC) 10 and the IP that, due to the specified TCAP message packet types, results in transactions that are never completed. The problem of incomplete TCAP transactions is illustrated by the telecommunications network 9, which includes an MSC 10, a Service Control Function 20 (SCF), and an IP 30. To connect the IP 30 to the MSC 10, it must be received. a message by the SCF 20 to prompt the issuance of a Connection Resource message, such as a Request of Origin, Request of Location, Transfer Occupancy, or Transfer without Response. In the case of Figure 1, the Call Origin Request Invoice message 40 is sent from the MSC 10 to the SCF 20 associated with the origin trigger. After the message of invoking Request of Origin is received and processed by SCF 20, it is sends a message 50 of Invoking Connection Resource from the SCF 20 to the MSC 10, requesting to establish a connection between the MSC 10 and the IP 30. In response to the message 50 of Invoking Connection Resource, the MSC 10 directs the incoming call to the IP 30, during establishment 60 of the call. Various events can then take place between the subscriber served by the MSC 10 and the IP 30. However, due to problems of 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 failure point 70. A message 80 to invoke connection failure report (having a type of conversation pack without permission) is then sent from MSC 10 to inform SCF 20 of the type and cause of failure 70. However, since the message 80 is sent with a type of "conversation without permission" package, any type of response presented to the MSC 10 will result in an error. For example, the Origin 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 type of "talk without permission" packet. As noted above, message 80 of Invoke Connection Failure Report is included as part of the same TCPA transaction initiated by other ANSI-41 messages, of which Message 40 of Invoke Petition of Origin is only one. The specification for the TCAP package type is defined in the WIN PN- ^ 3661 standard incorporated for reference herein in its entirety as a supplement to the ANSI-41 standard. Since the Origin 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. Said result is not only inconvenient to the mobile subscriber, but it wastes valuable network resources by maintaining a connection that fails to benefit from the use of IP 30. Eventually some kind of termination activity may result, such as a time out at the address of MSC 10, but this does not occur as a result of the information that is received from SCF 20 with respect to failed communication to 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 voicemail system. In general, there is a need to provide a method for the relative termination of TCAP transactions where network communication failures occur between an MSC and an IP when an Invoke Connection Failure Report is sent from the MSC to to the SCF requesting originally the connection between the MSC and the IP. Even more ^^^^^? fe ^^^^ gM ^^^^ & ^^ a_ there is generally a need for a method to provide the termination of the relative TCAP transaction 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 ANSI-41 and PN-3661 standards to provide permit conversation as a packet type for some messages, such as the message to invoke connection failure report, which prevents such relative termination.

COMPENDIUM OF THE INVENTION The present invention solves the above problem that concerns the relative closure of TCAP transactions, even when unexpected IP communication failures occur. The problem is eliminated by modifying the package type specified for some ANSI-41 and PN-3662 messages to include "permission conversation". Said type of packet allows the reception and processing of the response messages by the node that originates the message with the modified packet type. The node receiving the message having the modified packet type is accordingly given permission to generate an appropriate response message, which allows the relative closure of the TCAP transaction. Messages that have a modified package type include km. -. »Ad Sé. faith A * l Summon ANSI-41 and PN-3662 messages, such as the Summon Connection Failure Report message. More specifically, in a first implementation of the method, wherein a WIN comprises a first node, a second node, and a third node coupled in a TCAP transaction, and the first and third node experience an unexpected network communication failure. , the method that supports the closing of 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, and sending a second message requesting the first node to initiate the communication between the first node and the third node, in response to the first message; establish communication between the first and third nodes; experience a communication failure between the first and third node; send a third message that has a type of "talk with permission" packet from the first to the second node in response to the failure; and closing the TCAP transaction without conversation permission errors when sending a fourth message from the second node to the third node in response to the first message. The first node can be a Mobile Switching center. The second node can be selected from a service control point, a local location record, or a service node. The third node can be any of several intelligent peripherals, such as one that allows the network to implement speech recognition, storage of FAX messages, or storage of voice messages. The first, second and third messages are typically Summon ANSI-41 messages. For example, the third message may be an Invoke Connection_Fail_Report message, and the S / R through with a fourth underlined connection message may be a Request of Origin response. Additionally, the first message may be an Invoke Request to Origin message, and the second message may be a Call Invoke Connection message. The first, second and third messages can also be characterized as unanswered 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 can be acquired with reference to the following Detailed Description when taken in conjunction with the accompanying drawings in which: FIGURE 1, previously described, is an operation diagram Nodal and signal flow illustrating a failed TCAP transaction using ANSI-41 messaging in the prior art; FIGURE 2 is a diagram of nodal operation and signal flow illustrating the method of the present invention wherein a TCAP transaction is appropriately terminated in response to a network communication failure; and FIGURE 3 is a diagram of nodal operation and signal flow illustrating the method of the present invention adapted to communication with a service control point.

DETAILED DESCRIPTION Reference is now made to Figure 2, which illustrates a diagram of nodal operation and signal flow for the method of the present invention. In this illustration, the message of Summon Connection Failure Report has been assigned to a TCAP packet type of "conversation with permission" and therefore, the transaction can be terminated relatively (ie 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 to the failure point 70, that is, a message 40 (first message) is sent to Summon Request for Origin from the MSC 10 to the SCF 20, which is ived and processed, and urges the SCF 20 to send a message 50 (second message) of Summon Connection Resource from the SCF 20 to the MSC 10 to request the MSC 10 to connect to IP 30. The call is established in step 60, and communication between MSC 10 and IP 30 occurs up to point 70 of unexpected failure. In the method of the present invention, a TCAP packet type of "talk with permission" is specified for message 100 (third message) of Summon Connection Failure Report, instead of the identifier of the pack type of "conversation without permission". "in message 80 of Figure 1. In this scenario, the packet type identifier specified from" conversation with permission "for Message 100 of Invoke Connection Failure Report allows the continuous processing of the TCAP transaction and allows the Origin Request Request message 110 (fourth message) is processed by the MSC 10. In this scenario, no conversation permission error occurs because the message 100 of Invoke Connection Failure Report was sent using the packet type of "conversation with permission". Reference is now made to Figure 3, where a diagram of nodal operation and signal flow is shown illustrating how the present invention can be applied to the scenario where MSC 10 communicates with a service control point 120 (SCP), and, after the connection has been successfully established with an IP 30, the connection fails 4- ** - ** £. '' S * faith Í. ^ j ^^ H unexpectedly. The scenario can also apply to the application of the invented method to the unexpected failure of a? 4 k connection to a service node (SN). The illustration is for example purposes only, and it should be readily apparent to those skilled in the art that the MSC 10, SCP 120, IP30 and SCF 20 can all be represented as generic nodes in a WIN 9. For example, the MSC 10 can be considered as a first node, the SCF 20 and SCP 120 (or, alternatively, a Local Location Register) can considered as a second node, and IP 30 can be considered as a third node. The IP 30 may be used to implement speech gnition within the network 9 or the IP 30 may be used to implement storage of FAX messages, storage of voice messages, etc., within the network 9.

In Figure 3, the TCAP transaction, involves a Petition of Origin transaction between MSC 10 and SCP 120. Of course, those skilled in the art will gnize that the flow of similar information appears in the context of other operations that involve an MSC 10 and a Network Entity (NE) Service Logic. For example, the operation may include an Analyzed Information message between the MSC 10 and the SCP 120, or for origins or terminations, and may occur within the context of a Service Request between two network nodes. In this particular scenario, the MSC service 10 sends an Origin Request message 130 to SCP 120 associated with the origin trigger, based on the Mobile Identification Number (MIN), Mobile Directory Number (MDN) and Type of Trigger (TT). SCP 120 then determines that an IP 30 is required to identify the calling party, and sends a Capture Resource message 140 specifying the SRF Capability (ie the requested specialized resource capabilities, which includes the type of resource specialized standard requested, which includes the standard type of specialized resource requested, and the type of specialized private resource requested), and the Preferred Language Indicator (PLIND), which designates the preferred language for identification. The catch-up resource message 140 is sent to the speaker-dependent IP 30 associated with the caller, requesting necessary resource. In response to message 140 of the Collection Resource, IP 30 assigns a Temporary Local Directory Number (TLDN), which is returned to SCP 120 in message 150 of the Collection Resource response, for access to the resource. special appropriate. The SCP 120 is capable after passing the IP 30 TLDN MSC 10 service in a Connection Resource message 160, which also contains the carrier digits (CARDGTS), if applicable, and the special route instructions (ROUTDGTS), if is applicable. At this time, the SCP 120 establishes the WIN Response Timer (WINRT) for .SMSiffiμBMhib. ,. . . . .. ... i i. wait for the Instruction Request message from the IP 30. The Reset Timer (REST) is set to end before the Service Switching Function Timer of the MSC 10 (SSFT). If the WINRT actually expires, a Reset Timer message will be sent to the MSC 10 to start and restart the SSFT timer. The MSC 10 directs the subscriber's call to IP 30 using the specific TLDN in the call setup stage 60. When the call is received, IP 30 sends a Request for Instruction message to SCP 120 to request instructions for operation. At this time, communication between the subscriber and IP 30 is established and continues in the normal way. However, at some point, the MSC 10 determines that the connection between the subscriber and the IP 30 has unexpectedly failed at the failure point 70. Failure point 70 can occur at any time after call establishment 60 is completed, but in this particular scenario it can be assumed that it occurs almost immediately after the NSC 10 to IP 30 connection has been established. types of failure; the illustrated scenario assumes that the communication with IP 30 has been interrupted, but the subscriber has not disconnected. After detecting a failure in the IP connection 30, the MSC 10 stops the SSFT timer and sends a message 180 of Invoke Connection Failure Report to SCP 120, which includes the Fail Type (FAILTYPE) and the Fault Cause (FAILCAUSE ). In this case, the type of failure is a • "resource disconnection" and the Cause of Failure is received from the ISDN User Part, SCP 120 in this scenario receives message 180 to invoke connection failure report before an SRF Directive message has been sent (SRFDIR) to IP 30. Therefore, SCP 120 sends an Instruction Request response message 190 to IP 30 without sending an SRFDIR message to IP 30. • 10 Depending on the specific service logic program running in SCP 120, any of several actions can be undertaken. For example, SCP 120 may select the same IP 30 to send another Capture Resource message, trying to re-establish the 15 network-subscriber interaction. Alternatively, the SCP 120 may select an alternate IP 30 for attempts to reestablish the network-user interaction. In the scenario illustrated in Figure 3, SCP 120 sends a Request for Origin Response message that includes a 20 Action Code parameter (ACTCODE) which instructs MSC 10 to disconnect the call. In any case, the TCAP transaction closes relatively, and processing of the Origin Request response message 200 is allowed by the MSC 10 since the message 180 of Invoking Connection Failure Report is specified to have a type of TCAP package & »^ s ^^ m ^^ i" conversation with permission ". It should be noted that the Origin Request message 130, the Connect Resource message 160, and ^ the Connection Failure Report 180 can all be characterized as unanswered messages that do not send in response to no particular question for a node in the WIN 9. These messages 130, 160 and 180 are also illustrated in Figure 3 as TCAP Summon 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 have been described which relate to ANSI-41 Origin Request messages, it should be understood that modifications of the similar package type can be made that support the transaction closure of TCAP to others.

ANSI-41 messages including, for example, Location Request, Feature Request, Transfer Request to Number, Analyzed Information, Selected and Available Facility, Service Request, Transfer Occupancy, and Unanswered Transfer. Although the Preferred embodiments of the method of the present invention are illustrated in the accompanying drawings and described in the above detailed description, it will be understood by those skilled in the art that the invention is not limited to the described embodiments, but is capable of numerous arrangements, modifications, substitutions without departing from the spirit of , i7. the invention as set forth and defined in the following claims.

Claims (20)

1. CLAIMS 1. In a wireless intelligent network comprising a first node, a second node, and a third node coupled in a Transaction Capability Application Part (TCAP), wherein the first and third nodes experience a network communication failure not expected, a method that supports the closing of the transaction without creating conversation permission errors comprising 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; establish a communication between the first node and the third node in response to the second message; experience in 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 in response to communication failure between the first and third nodes, the third message having a type of "talk with permission" packet; and closing the TCAP transaction without creating conversation permission errors when sending a fourth message from the second node to the first node in response to the first message.
2. 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. 3. The method of claim 1, wherein the third message is a Message to Summon Connection Failure Report and the fourth message is a Request of Origin Response.
4. 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 one selected from a Service Node (SN), a Local Location Register (HLR), or a Service Control Point (SCP).
7. The method of claim 1, wherein the third node is used to implement speech recognition within the network.
8. The method of claim 1, wherein the third node is used to implement storage of fax messages within the network.
9. 9. The method of claim 1, wherein the third node is used to implement storage of bgj voice messages within the network.
10. 10. In a wireless intelligent network comprising a first node, a second node, and a third node coupled in a Transaction Capability Application Part (TCAP), wherein the first and third nodes experience a non-network communication failure. Expected, a method that supports closing the transaction without creating conversation permission errors comprises the steps of: opening a TCAP transaction by sending a first unanswered message from the first node to the second node; receiving the first unanswered message in the second node and sending a second unanswered message from the second node to the first node, wherein the second unanswered message requests the first node to initiate communication between the first node and the third node; establishing a communication between the first and the third node is a response to the second unanswered message; experience in the first node a failure in the communication established between the first and third nodes; sending a third unanswered message from the first to the second node in response to the communication failure between the first and third nodes, the third unanswered message having a type of "talk with permission" packet; and closing the TCAP transaction without creating conversation permission errors when sending a fourth message from the second node to the first node in response to the first message.
11. 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 unanswered message is a Message Summon Connection Failure Report and the fourth message is a Request of Origin Response.
13. The method of claim 10, wherein the first unanswered message is an INVOK message.
14. The method of claim 10, wherein the first, second, and third unanswered messages are INVOKE messages.
15. The method of claim 10, wherein the second node is one selected from a Service Node (SN), a Local Location Register (HLR), or a Service Control Point (SCP).
16. The method of claim 10, wherein the third node is used to implement speech recognition within the network.
17. The method of claim 10, wherein the third node is used to implement storage of fax messages within the network.
18. The method of claim 10, wherein the third node is used to implement storage of voice messages within the network.
19. 19. In a wireless intelligent network comprising a Mobile Switching Center (MSC), a Service Control Function (SCF), and a Smart Peripheral(IP) coupled in a transaction Transaction Capability Application Part (TCAP) transaction, where the MSC and the IP experience an unexpected network communication failure, a method that supports the closing of the transaction without creating permission errors Conversation comprising the steps of: opening a TCAP transaction by sending a Request Originating Request message from the MCS to the SCF; send an Invoke Connecting Resource message from the SCF to the MSC, in response to the Invoke message Request of Origin, where the message of Invoke Connection Resource requests the first node to initiate the communication between the first node and the IP; establish a communication between the MSC and the IP in response to the Invoke Connection Resource message; experience in the MSC a communication failure established between the MSC and the IP; •:, l £ i * í ^. send a message of Summon Connection Failure Report from the MSC to the SCF in response to communication failure between the MSC and the IP, having the third message Invoke Connection Failure Report a packet type of 5"conversation with permission "; and closing the TCAP transaction without creating conversation permission errors when sending a Request of Origin response message from the SCF to the MSC in response to the Summon Request of Origin message.
20. 20. The method of claim 19, wherein the • SCF is a Service Control Point (SCP). • '• **** - ~ - * - "- - ^ smia? A ^