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

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 word

Trang 1

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

Protocol 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 protocol 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

Trang 2

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

Application 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

End-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

Trang 3

Handling 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 >

Trang 4

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

Begin Message

The Begin Message is sent to initiate a transaction Table 10-10 lists the message contents

Trang 5

Table 10-10 Begin Message Fields

Message Type

Mandatory

Originating Transaction ID Tag

Transaction ID Length

Transaction ID

Mandatory

Optional[*]

One or More Components Optional

[*]

The component Portion Tag is present only if the message contains components

EndMessage

The End Message is sent to end a transaction Table 10-11 lists the message

contents

Table 10-11 End Message Fields

Message Type

Mandatory

Destination Transaction ID Tag

Transaction ID

Mandator

Trang 6

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

Message Type

Mandatory

Originating Transaction ID Tag

Transaction ID

Mandatory

Transaction ID

Mandatory

Optional[*]

Trang 7

The component Portion Tag is present only if the message contains components

Abort Message

The Abort Message is sent to terminate a previously established transaction Table 10-13 lists the message contents

Table 10-13 Abort Message Fields

Message Type

Mandatory

Transaction ID

Mandatory

P-Abort Cause Tag

P-Abort Cause Length

P-Abort Cause

Optional[*]

[*]

P-Abort is present when the TC-User generates the Abort message

Định dạng
Số trang	7
Dung lượng	48,15 KB