Signaling System No.7 Protocol Architecture And Sevices part 34 pot

Message Types The TCAP message type which is referred to as package type in ANSI identifies the type of message being sent within the context of a transaction.. Query with Permission 111

Message Types

The TCAP message type (which is referred to as package type in ANSI) identifies the type of message being sent within the context of a transaction Table 10-1 lists the seven package types for ANSI and Table 10-2 lists the five message types for ITU

Table 10-1 Package Types for ANSI

ANSI Package

Types

Hex Value

Description

Unidirectional 11100001 Sent in one direction and expects no reply

Query with

Permission

11100010 Initiates a transaction, giving the receiving node

permission to end the transaction

Query without

Permission

11100011 Initiates a transaction but does not allow the

receiving node to end the transaction Response 11100100 Ends a transaction

Conversation with

Permission

11100101 Continues a transaction, giving the receiving

node permission to end the transaction

Conversation

without Permission

11100110 Continues a transaction, but does not allow the

receiving node to end the transaction

Abort 11110110 Sent to notify the destination node that an

established transaction has been terminated without sending any further components that might be expected

Table 10-2 Message Types for ITU

ITU Message

Types

Hex Value

Description

Unidirectional 01100001 Sent in one direction and expects no reply

Begin 01100010 Initiates a transaction

(Reserved) 01100011 Not used

End 01100100 Ends a transaction

Continue 01100101 Continues an established transaction

(Reserved) 01100110 Not used

Abort 01100111 Sent to notify the destination node that an

established transaction has been terminated without sending any further components that might be expected

The message type also infers the stage of transaction processing Figure 10-4

shows an example of an ITU conversation and an equivalent ANSI conversation

In ITU, a Begin message always starts a transaction, and an End message normally ends the transaction (The "Transactions" section of this chapter discusses an

exception to this rule.) The equivalent ANSI messages that begin and end

transactions are Query (with or without permission) and Response, respectively Conversation (ANSI) and Continue (ITU) messages indicate that further

communication is required in an existing transaction

Figure 10-4 Examples of ITU and ANSI Message Flow

< Day Day Up >

< Day Day Up >

Transactions

The services that use TCAP vary in complexity Some require a node to translate and receive only a single message For example, a basic toll-free call typically works in this manner Other services, such as Call Completion to a Busy

Subscriber (CCBS), can exchange a number of messages between nodes

A transaction is a set of related messages that are exchanged between application processes at two different nodes At any time, a node can have many simultaneous transactions in progress and send and receive multiple TCAP messages For

example, several subscribers might invoke a CCBS during the same period of time NOTE

CCBS is a subscriber feature used for completing calls to a busy subscriber by monitoring the called party's line and completing a call attempt when the called party is free TCAP messages are exchanged between the telephony switches of the calling and called parties to monitor the busy line and provide notification when it

is free The service is also popularly known as Automatic Callback

When a node sends a message and expects a reply, the sending node establishes and maintains a Transaction ID This allows an incoming message to be properly associated with previously sent messages

Transaction IDs

Transactions always begin with an initiating TCAP message that contains an

Originating Transaction ID When the service has completed, the Transaction ID becomes available for use again by the application Each transaction must have a unique Transaction ID for all outstanding transactions When an ID is in use, it cannot be used again until the current transaction releases it If the same ID

belonged to two transactions, the system that received a message would not know the transaction to which it belonged The ANSI Transaction ID is 4 octets in

length, thereby allowing a total number of 232 concurrent transactions to exist at a given time The ITU Transaction ID is variable from 1 to 4 octets Up to two

Transaction IDs can be included in a TCAP message, an Originating Transaction

ID, and a Responding Transaction ID (called a Destination Transaction ID in ITU) ANSI packages the Transaction IDs differently than ITU by nesting both IDs

within a single Transaction ID Identifier The following figure shows the

Transaction ID section

Figure 10-5 Transaction ID Format

Establishing Transaction IDs

The node that originates the transaction assigns an Originating Transaction ID, which the node sends to the destination in the first message, to establish the

transaction When the destination node receives a message, the application

examines its contents and determines whether it should establish its own

transaction

When the destination node responds to the originating node, the message that is sent contains a Responding (or Destination) Transaction ID The Responding

Transaction ID is the same as the Originating Transaction ID that was received in the Begin/Query message It can be thought of as a reflection of the Originating

ID The destination node examines the contents of the message to determine if it should establish a transaction with the originating node If establishing a

transaction is necessary, an Originating Transaction ID is assigned by the

responding destination node and placed in an ANSI Conversation or ITU Continue message along with the Responding Transaction ID to be sent back to the

transaction originator In this situation, each node establishes a transaction from its own point of view Depending on the message type, a TCAP message can contain zero, one, or two Transaction IDs Tables 10-3 and 10-4 show the relationship between a message type and Transaction IDs for ITU and ANSI, respectively For example, in Table 10-3, a Unidirectional message does not contain any Transaction IDs, while a Continue message contains two Transaction IDs

Table 10-3 ITU Message Transaction IDs

ITU Message Type Originating Transaction ID Destination Transaction ID

Table 10-4 ANSI Message Transaction IDs

ANSI Package Type

Originating Transaction ID

Responding Transaction ID

Conversation with

Permission

Yes Yes

Conversation without

Permission

Yes Yes Abort No Yes

Releasing Transaction IDs

The communicating applications can end transactions in one of two ways: either with a terminating message or a prearranged end The most common method is a terminating message—a Response package in ANSI and an End message in ITU The prearranged transaction end is simply an agreement at the application layer that a transaction ends at a given point Releasing the Transaction ID returns it to the available pool of IDs so that another transaction can use it

Transaction Message Sequence

Applications do not always establish a transaction during TCAP communications The Unidirectional message is used to communicate when no reply is expected, therefore, requiring no Transaction ID All other messages require a Transaction

ID

Figure 10-6 shows an example of a transaction occurring between two SS7 nodes

A conversation is established between Node A and Node B As mentioned

previously, a Query or Begin message always initiates a transaction Node A

establishes a transaction with a Transaction ID of 0 When the service logic at Node B processes the incoming message, it determines that it is necessary to

establish a transaction from its own point of view This is usually done to request additional information from the node that sent the message In this example using the ANSI protocol, node B does not have a choice about engaging in a

conversation because it has received a "Query without Permission" message The message's "without Permission" designation is used to deny the receiving node the opportunity to end the transaction until it receives permission In this example, Node B initiates a transaction with a Transaction ID of 1, thereby associating it with the received Transaction ID of 0

Figure 10-6 Transaction Example Using ANSI Protocol

Figure 10-7 shows the same transaction using the ITU protocol As shown by comparing the two examples, the two protocols are conceptually quite similar Other than naming conventions and binary encoding, the primary difference is that the ITU message types do not explicitly state whether the receiving node must engage in a transaction from its perspective This must be determined from the application logic

Figure 10-7 Transaction Example Using ITU Protocol