CA2373206A1 - Transaction capabilities application part (tcap) transaction termination method - Google Patents
Transaction capabilities application part (tcap) transaction termination method Download PDFInfo
- Publication number
- CA2373206A1 CA2373206A1 CA002373206A CA2373206A CA2373206A1 CA 2373206 A1 CA2373206 A1 CA 2373206A1 CA 002373206 A CA002373206 A CA 002373206A CA 2373206 A CA2373206 A CA 2373206A CA 2373206 A1 CA2373206 A1 CA 2373206A1
- Authority
- CA
- Canada
- Prior art keywords
- node
- message
- transaction
- response
- msc
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
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 in 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 in 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 CcnnectResource message, such as an OriginationRequest LocationRequest, TransferBusy, or TransferNoAnswer message. In the case of Fig. l, 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 received and processed by the SCF 20, a ConnectResource Invoke message 50 is sent from the SCF
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 20 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 Fai lure Report Invoke message 80 is included as part of the same .CAP transaction initiated by other ANSI-41 messages, of which the Origination Request Invoke message 40 is but one. The specification for the TCAP package type is defined in the WIN PN-3661 standard incorporated by reference herein in 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 network communication failures occur between a MSC and an IP when 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 networ'.~: 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 in 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, in 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 second node in response to the failure;
and closing the TCAP transaction without conversation permission errcrs by sending a fourth message frcm the second node to the third node in response to the first message.
The first node may be a mobile switching center.
The second node may be selected from a service control point, a home location register, or a service node.
The third node may be 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, second, and third messages are typically ANSI-41 Invoke messages. For example, the third message may be a Ccnnection Failure 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 ir. 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 in response to a network communication failure; and FIGURE 3 is a signal flow and nodal operation diagram illustrating the method of the present invention adapted ~:, 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 Ccnnection Failure Report Invoke message has been assigned a TCAP package type of "conversation with permission," and t?:erefore, 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 t:~:e failure point 70. That is, an Origination Request Invoke message (first message) 40 is sent from the i~SC 10 to the SCF 20, which is received and processed, and prompts the SCF 20 to send a Connect Resource Invoke message (second message) SO
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 ~ccnversation 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 conversaticr_ permission error occurs in this scenario because the Connection Failure Report Invoke message 100 was sent using the package type of ~conversation with permission."
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 in 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 in 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 CcnnectResource message, such as an OriginationRequest LocationRequest, TransferBusy, or TransferNoAnswer message. In the case of Fig. l, 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 received and processed by the SCF 20, a ConnectResource Invoke message 50 is sent from the SCF
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 20 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 Fai lure Report Invoke message 80 is included as part of the same .CAP transaction initiated by other ANSI-41 messages, of which the Origination Request Invoke message 40 is but one. The specification for the TCAP package type is defined in the WIN PN-3661 standard incorporated by reference herein in 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 network communication failures occur between a MSC and an IP when 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 networ'.~: 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 in 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, in 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 second node in response to the failure;
and closing the TCAP transaction without conversation permission errcrs by sending a fourth message frcm the second node to the third node in response to the first message.
The first node may be a mobile switching center.
The second node may be selected from a service control point, a home location register, or a service node.
The third node may be 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, second, and third messages are typically ANSI-41 Invoke messages. For example, the third message may be a Ccnnection Failure 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 ir. 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 in response to a network communication failure; and FIGURE 3 is a signal flow and nodal operation diagram illustrating the method of the present invention adapted ~:, 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 Ccnnection Failure Report Invoke message has been assigned a TCAP package type of "conversation with permission," and t?:erefore, 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 t:~:e failure point 70. That is, an Origination Request Invoke message (first message) 40 is sent from the i~SC 10 to the SCF 20, which is received and processed, and prompts the SCF 20 to send a Connect Resource Invoke message (second message) SO
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 ~ccnversation 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 conversaticr_ permission error occurs in this scenario because the Connection Failure Report Invoke message 100 was sent using the package type of ~conversation with permission."
Reference is new made to Fig. 3, wherein is shown a signal flow and nodal operation diagram illustrating the present invention as it may be applied to the scenario where 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 in 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 ~0 may be 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 in the context of other operations which involves an MSC 10 and a service logic Network Entity (NE). For example, the operation may include an AnalyzedInformation 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 the 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
using the specified TLDN at call setup step 60.
When the call is received, the IP 30 sends an 30 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, but 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 in 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 to 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 ~.onnection 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 i:: response to any particular query by a node in 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 in the following claims.
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 in the context of other operations which involves an MSC 10 and a service logic Network Entity (NE). For example, the operation may include an AnalyzedInformation 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 the 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
using the specified TLDN at call setup step 60.
When the call is received, the IP 30 sends an 30 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, but 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 in 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 to 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 ~.onnection 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 i:: response to any particular query by a node in 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 in the following claims.
Claims (20)
1. 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 is 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 in response to the failure in ccmmunication 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.
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 in response to the failure in ccmmunication 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 method of Claim 1, wherein the third message is a Connection Failure Report Invoke 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 third 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.
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.
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 tine 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.
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 tine 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).
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US30425599A | 1999-05-03 | 1999-05-03 | |
| US09/304,255 | 1999-05-03 | ||
| PCT/SE2000/000694 WO2000067492A1 (en) | 1999-05-03 | 2000-04-11 | Transaction capabilities application part (tcap) transaction termination method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2373206A1 true CA2373206A1 (en) | 2000-11-09 |
Family
ID=23175734
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002373206A Abandoned CA2373206A1 (en) | 1999-05-03 | 2000-04-11 | Transaction capabilities application part (tcap) transaction termination method |
Country Status (6)
| Country | Link |
|---|---|
| JP (1) | JP2002543718A (en) |
| AU (1) | AU4787800A (en) |
| BR (1) | BR0010258A (en) |
| CA (1) | CA2373206A1 (en) |
| MX (1) | MXPA01011084A (en) |
| WO (1) | WO2000067492A1 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005125222A1 (en) * | 2004-06-22 | 2005-12-29 | Zte Corporation | Method for protecting incoming calls in personalized ring back tone service |
| CN100525482C (en) * | 2004-11-30 | 2009-08-05 | 中兴通讯股份有限公司 | Intellight network mode personized ring back tone calling protection method and device |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6011969A (en) * | 1997-06-13 | 2000-01-04 | Telefonaktiebolaget L M Ericsson | TCAP package type specification for ANSI-41 MAP messages in order to support MAP operation closure |
| EP0926908A1 (en) * | 1997-12-24 | 1999-06-30 | TELEFONAKTIEBOLAGET L M ERICSSON (publ) | Timeout handler in a service control point |
-
2000
- 2000-04-11 MX MXPA01011084A patent/MXPA01011084A/en unknown
- 2000-04-11 JP JP2000614744A patent/JP2002543718A/en not_active Withdrawn
- 2000-04-11 WO PCT/SE2000/000694 patent/WO2000067492A1/en active Application Filing
- 2000-04-11 CA CA002373206A patent/CA2373206A1/en not_active Abandoned
- 2000-04-11 AU AU47878/00A patent/AU4787800A/en not_active Abandoned
- 2000-04-11 BR BR0010258-0A patent/BR0010258A/en not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| WO2000067492A1 (en) | 2000-11-09 |
| MXPA01011084A (en) | 2002-06-04 |
| BR0010258A (en) | 2002-05-21 |
| AU4787800A (en) | 2000-11-17 |
| JP2002543718A (en) | 2002-12-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2375715B1 (en) | Event processing system in a communication network | |
| US5896441A (en) | Communication state management system and method in an intelligent network | |
| WO1997043850A2 (en) | Call transfer in a cellular telephone network | |
| US6011969A (en) | TCAP package type specification for ANSI-41 MAP messages in order to support MAP operation closure | |
| US7050811B2 (en) | Method of setting up an application initiated call to a mobile station within a CAMEL network, and a telecommunications system comprising a CAMEL network | |
| AU731257B2 (en) | Method and apparatus for providing calling service features within incompletely upgraded cellular telephone networks | |
| WO2001031935A1 (en) | Feature interactions | |
| EP0966142B1 (en) | Apparatus method and system for controlling secondary treatment by a distant switch for multiple leg telecommunication sessions | |
| RU2372745C2 (en) | Method of providing of calls processing for user of intelligent network | |
| US20020018551A1 (en) | Initiation of services in telecommunications network | |
| US20050213520A1 (en) | Method and system for disconnecting a terminating connection Leg (Leg2) for enhanced dialed services in a mobile intelligent network | |
| CA2373206A1 (en) | Transaction capabilities application part (tcap) transaction termination method | |
| CZ20001186A3 (en) | Authentication method of mobile radio telephone network subscribers | |
| US6771762B1 (en) | System and method for call merge to an AIN SSP from an intelligent peripheral | |
| US6947541B2 (en) | Enhancing an intelligent network service | |
| FI105981B (en) | Procedure for leaving the subscriber information collection phase in an intelligent network | |
| US7203180B2 (en) | Initiating service logic | |
| EP1042926B1 (en) | Timeout handler in a service control point | |
| KR100330179B1 (en) | Intelligent Network Processing Method For Outgoing Call In Switching System | |
| US6459786B1 (en) | Call and connection control | |
| CN101578888B (en) | Invoking a service in an interlligent network | |
| US20030147418A1 (en) | Multiple dialogues on connection-oriented TCAP transaction | |
| NZ288292A (en) | Switching link between networks operable by service processor, switching separated from logical validation | |
| KR100285504B1 (en) | Method for accessing between intelligent network system and intelligent peripheral | |
| BRPI0807169A2 (en) | CALL CONNECTION METHOD, SYSTEM AND DEVICE |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued | ||
| FZDE | Discontinued |
Effective date: 20040413 |