Signaling System No.7 Protocol Architecture And Sevices part 37 docx

Error Handling
As with any other protocol, errors can occur during TCAP communications. TCAP
errors fall into three general categories:
• Protocol Errors
• Application Errors
• End-user Errors
P
rotocol Errors
Protocol Errors are the result of TCAP messages being incorrectly formed,
containing illegal values, or being received when not expected. For example,
receiving an unrecognized message type or component type would constitute a
p
rotocol error. Another example of an error would be receiving a responding
Transaction ID for a nonexistent transaction. While the actual value of the ID
might be within the acceptable range of values, the lack of a transaction with which
to associate the response causes a protocol error.
Errors at the Transaction Layer
Protocol Errors that occur at the transaction sublayer are reported to the remote
node by sending an Abort message type with a P-Abort cause—in other words, a
Protocol Abort. The Abort message is sent only when a transaction must be closed
and a Transaction ID can be derived from the message in which the error occurred.
Figure 10-13
shows an Abort message being sent for an open transaction in which
a protocol error is detected.
Figure 10-13. Protocol Error Causes an Abort


Because no Transaction ID is associated with a Unidirectional message, no Abort
message would be sent if the message was received with an error. If a Query or
Begin message is received and the Originating Transaction ID cannot be
determined because of the message error, the message is simply discarded and an

Abort message is not returned to the sender.
If the Transaction ID can be determined, the Abort message is sent to report the
error. Without the Transaction ID, there is no way for the sending node to handle
the error because it cannot make an association with the appropriate transaction.
Errors at the Component Layer
Protocol errors at the component sublayer are reported using a Reject Component.
The errored component's Component ID is reflected in the Reject Component. A
number of different errors can be detected and reported. For example, a duplicate
Invoke ID error indicates that an Invoke ID has been received for an operation that
is already in progress. This results in an ambiguous reference because both
operations have the same ID. Another type of error is a component that is simply
coded with an incorrect value, such as an unrecognized component type. Refer to
the TCAP specifications for a complete list of errors that can be detected and
reported.
A
pplication Errors
Application Errors are anomalies within the application procedure. An example is
an unexpected component sequence, in which the received components do not
match what the application procedures expect. Another example is a missing
customer record error, which is an error that is used to indicate that a database
lookup failed to find the requested information. The application is responsible for
determining what actions to take when errors of this type are encountered.
E
nd-User Errors
The End-User Error is similar to the Application Error in that it is an anomaly of
the application procedure. However, as indicated by the name, the anomaly is the
result of some variance from the normal actions by the user. The user might take
an action, such as abandoning the call prematurely, as shown in Figure 10-14
; or
the user might enter an unexpected response when connected to a digit collection

unit and prompted for input, thereby causing the error.
Figure 10-14. Error Caused by User Action


H
andlin
g
Application and End-User Errors
Both the Application Error and the End-User Error are reported using the Return
Error component for component-related errors. Because the errors in these two
categories are actually variations in the application's script or procedure flow, the
application determines how they are handled. These errors also imply that no error
exists at the actual TCAP layer because a protocol error would trigger prior to an
error at the application level. The application can also send an Abort message type
(U-Abort) to the other node to indicate that a User Abort has occurred for the
transaction and that it should be closed.

< Day Day Up >

< Day Day Up >

ITU Protocol Message Contents
The definition of each message type indicates a set of fields that comprise the
message. While some fields are mandatory, others are optional. As specified by
Q.773, the standard set of ITU messages includes:
• Unidirectional
• Begin
• End
• Continue
• Abort

The following sections describe these messages, the fields that are included in each
one, and indicate which fields are mandatory or optional.
Unidirectional Message
The Unidirectional Message is sent when no reply is expected. Table 10-9
lists the
message contents.
Table 10-9. Unidirectional Message Fields
Unidirectional Message Fields Mandatory/Optional
Message Type
Total Message Length
Mandatory
Dialogue Portion Optional
Component Portion Tag
Component Portion Length
Mandatory
One or More Componnts Mandatory

B
e
g
in Messa
ge

The Begin Message is sent to initiate a transaction. Table 10-10
lists the message
contents.
Table 10-10. Begin Message Fields
Begin Message Fields Mandatory/Optional
Message Type
Total Message Length

Mandatory
Originating Transaction ID Tag
Transaction ID Length
Transaction ID
Mandatory
Dialogue Portion Optional
Component Portion Tag
Component Portion Length
Optional
[*]

One or More Components Optional

[*]
The component Portion Tag is present only if the message contains components.
E
ndMessa
g
e
The End Message is sent to end a transaction. Table 10-11
lists the message
contents.
Table 10-11. End Message Fields
End Message Fields Mandatory/Optional
Message Type
Total Message Length
Mandatory
Destination Transaction ID Tag
Transaction ID Length
Transaction ID

Mandator
Dialogue Portion Optional
Component Portion Tag
Component Portion Length
Optional
[*]

One or More Components Optional

[*]
The component Portion Tag is present only the message contains components.
Continue Message
The Continue Message is sent when a transaction has previously been established
and additional information needs to be sent without ending the transaction. Table
10-12 lists the message contents.
Table 10-12. Continue Message Fields
Continue Message Fields Mandatory/Optional
Message Type
Total Message Length
Mandatory
Originating Transaction ID Tag
Transaction ID Length
Transaction ID
Mandatory
Destination Transaction ID Tag
Transaction ID Length
Transaction ID
Mandatory
Dialogue Portion Optional
Component Portion Tag

Component Portion Length
Optional
[*]

One or More Components Optional

[*]
The component Portion Tag is present only if the message contains components.
A
bort Messa
g
e
The Abort Message is sent to terminate a previously established transaction. Table
10-13 lists the message contents.
Table 10-13. Abort Message Fields
Abort Message Fields Mandatory/Optional
Message Type
Total Message Length
Mandatory
Destination Transaction ID Tag
Transaction ID Length
Transaction ID
Mandatory
P-Abort Cause Tag
P-Abort Cause Length
P-Abort Cause
Optional
[*]

Dialogue Portion Optional

[*]
P-Abort is present when the TC-User generates the Abort message.
