home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-31 | 55.4 KB | 2,783 lines |
- The drawings contained in this Recommendation have been done in Autocad.
- Recommendation Q.774
- TRANSACTION CAPABILITIES PROCEDURES
- 1 Introduction
- Transaction capabilities (TC) allows TC users to exchange components via
- transaction capabilities application part (TCAP) messages. Procedures described
- in this section specify the rules governing the information content and the
- exchange of TCAP messages between TC users.
- 1.1 Basic guideline
- To maximize flexibility in service architecture and implementation style,
- TCAP procedures restrict themselves to supporting the exchange of components
- between TC users. Application specific (TC user) procedures are not part of TCAP.
- When the selection of a parameter value associated with a primitive that
- is required by a lower layer (sub-layer) is not relevant to that layer
- (sub-layer), the value is simply passed down through the primitive interface. The
- same assumption applies to the parameters received from a lower layer through the
- primitive interface which are not required for TCAP functions.
- 1.2 Overview
- Section 2 describes addressing rules for TC messages. Section 3 describes
- transaction capabilities based on a connectionless network service. Section 4
- describes transaction capabilities based on a connection oriented network
- service.
- 2 Addressing
- In a Signalling System No. 7 environment using a connectionless network
- service, TC messages will use any of the addressing options afforded by the
- signalling connection control part (SCCP). Assignment and use of global titles
- may be network and/or application specific.
- Addressing options available for the intermediate service part (ISP) are
- for further study. Addressing options whene other network providers are used are
- for further study.
- 3 Transaction capabilities based on a connectionless network service
- 3.1 Sub-layering in TCAP
- TCAP procedure is divided into component sub-layer procedure and
- transaction sub-layer procedure. The component sub-layer procedure provides a TC
- user with the capability of invoking remote operations and receiving replies. The
- component sub-layer also receives dialogue control information from a TC user,
- and, in turn, uses transaction sub-layer capabilities for transaction control.
- The component sub-layer provides two kinds of procedures:
- - dialogue handling;
- - component handling.
- 3.2 Component sub-layer procedures
- 3.2.1 Normal procedure
- 3.2.1.1 Component handling procedure
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- 3.2.1.1.1 Mapping of TC component handling service primitives to component types
- Recommendation Q.771 describes the services provided by the component
- sub-layer by defining the service interface between the TC user and the component
- sub-layer and the interface between the component sub-layer and the transaction
- sub-layer. Component handling procedures map component handling service
- primitives onto components, which constitute the protocol data units (PDUs) of
- the component sub-layer. A mapping of these primitives to component sub-layer
- PDUs is indicated in Table 1/Q.774.
- 3.2.1.1.2 Management of component IDs
- Component IDs are assigned by the invoking end at operation invocation
- time. A TC-user need not wait for one operation to complete before invoking
- another. At any point in time, a TC-user may have any number of operations in
- progress at a remote end (although the latter may reject an invoke component for
- lack of resources).
- Each component ID value is associated with an operation invocation and its
- corresponding component state machine. Management of this component ID state
- machine takes place only at the end which invokes the operation. The other end
- reflects this component ID in its relies to the operation invocation, and does
- not manage a state machine for this connection ID. Note that both ends may invoke
- operations in a full-duplex manner: each end manages state machines for the
- operations it has invoked, and is free to allocate component IDs independently of
- the other.
- A component ID value may be reallocated when the corresponding state
- machine returns to idle. However, immediate reallocation could result in
- difficulties when certain abnormal situations arise. A released ID value (when
- the state machine returns of idle) should therefore not be real-located
- immediately; the way this is done is implementation-dependent, and thus is not
- described in this Recommendation.
- Component states and state transitions are described in S 3.2.1.1.3.
- TABLE 1/Q.774
- Mapping of TC component handling service primitives to
- components
-
- Service Primitive Abbreviation Component Type
- TC-INVOKE INV INVOKE (Note 1)
- TC-RESULT RR-L Return Result (Last) (Note
- 1)
- TC-U-ERROR RE Return Error (Note 1)
- TC-U-REJECT RJ Reject (Note 1)
- TC-R-REJECT RJ Reject (Note 1)
- TC-L-REJECT (Note 2)
- TC-RESULT-NL RR-NL Return Result (Not Last)
- TC-L-CANCEL (Note 3)
- TC-U-CANCEL
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- (Note 3)
- Note 1 - X.219 and X.229 Compatible.
- Note 2 - Treatment of this primitive is described in S 3.2.2.2.
- Note 3 - There is no component type associated with this primitive since the
- effect is purely local.
-
- 3.2.1.1.3 Operation classes
- TABLE 2/Q.774
- Operation Classes
-
- Operation Class Description
- 1 Reporting success or failure
- 2 Reporting failure only
- 3 Reporting success only
- 4 Outcome not reported
- A different type of state machine is defined for each class of operation,
- the state transitions of which are represented by Figures 1/Q.774 to 4/Q.774.
- These state machines are described here from a protocol point of view
- (sent/received components), whereas they are described in Recommendation Q.771
- from a service (primitives) point of view.
- The states of each component state machine are defined as follows:
- - Idle:The component ID value is not assigned to any pending operation.
- - Operation Sent: The component ID value is assigned to an operation
- which has not been completed or rejected.
- - Wait for Reject: When a component indicating the completion of an
- operation is received, the receiving TC-user may reject this result.
- The Wait for Reject State is introduced so that the component ID is
- retained for some time, thereby making the rejection possible.
- State transitions are triggered by:
- - a primitive received from the TC-user, causing a component to be built,
- and eventually sent;
- - receipt of a component from the peer entity;
- - a number of situations indicated on Figures 1/Q.774 to 4/Q.774,
- corresponding to the following situations:
- Cancel: A timer is associated with an operation invocation. This
- invocation timer is started when the invoke component is passed to the
- transaction sub-layer. The TC-INVOKE request primitive indicates a timer value. A
- cancel situation occurs when the invoking TC-user decides to cancel the operation
- (TC-U-CANCEL request primitive) before either the final result (if any) is
- received, or a timeout situation occurs. On receipt of a TC-U-CANCEL request, the
- component sub-layer stops the timer; any further replies will not be delivered to
- the TC-user, and TCAP will react according to abnormal situations as described in
- S 3.2.2.2.
- End situation: When an End or Abort message is received, or when
- prearranged end is used, TCAP returns any pending operations to Idle.
- Invocation timeout: A timeout situation occurs when the timer associated
- with an operation invocation expires: the state machine returns to idle, with
- notification to the TC-user by means of a TC-L-CANCEL indication (in the case of
- a class 1, 2 or 3 operation). This notification indicates an abnormal situation
- for a class 1 operation, or gives the definite outcome of a class 2 or 3
- operation for which no result has been received (normal situation).
- Reject timeout: A Reject timeout situation occurs when the timer
- associated with the Wait for Reject state expires. If this occurs, the component
- sub-layer assumes that the TC-user has accepted the component.
- In the diagrams that follow, components contain either single ID values,
- or ordered pairs of IDs (i, y), where i is the invoke ID and y is the linked ID.
- The state diagrams are modeled for a single operation invocation with ID i. The
- value of y is not relevant to the ID i. A linked invoke operation can only be
- accepted if the linked to state machine is in the Operation Sent state.
- Components can be received "well-formed" or "malformed". The diagrams show
- where this is significant. If it does matter whether the component is received
- "well-formed" or "malformed" then the diagram indicates "receive" only.
- Class 1 operations report failure or success. A rejection in the case of a
- protocol error may also occur. Upon invoking a class 1 operation, the invoking
- end will keep the ID i active until a "last" reply is received and can no longer
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- be rejected. An ID may be released locally, at the option of the TC-user. This is
- indicated in Figure 1/Q.774.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. 1/Q.774 /T1113720-88 = 15 cm
-
- Class 2 operations report failure only. A rejection in the case of a
- protocol error may also occur. Upon invoking a class 2 operation, the invoking
- end will keep the ID i active until a reply has been received and can no longer
- be rejected or until a timeout1) cancel or end situation occurs. This is
- indicated in Figure 2/Q.774.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 1) A timeout for a class 2 operation is a "normal" situation.
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. 2/Q.774 /T1113731-88 = 15 cm
-
- Class 3 operations report success only. A rejection in the case of a
- protocol error may also occur. Upon invoking a class 3 operation, the invoking
- end will keep the ID i active until a reply has been received and can no longer
- be rejected or until a timeout2) cancel or end situation occurs. This is
- indicated in Figure 3/Q.774.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 2) A timeout for a class 3 operation is a "normal" situation.
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. 3/Q.774 /T1113730-88 = 15 cm
-
- Class 4 operations do not report their outcome. A rejection in the case of
- a protocol error may also occur. Upon invoking a class 4 operation, the invoking
- end will keep the ID i active until a reject has been received or until a
- timeout3) cancel or end situation occurs. This is indicated in Figure 4/Q.774.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 3) A timeout for a class 4 operation is a "normal" situation.
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. 4/Q.774 /T1113751-88 = 15 cm
-
- 3.2.1.2 Sample component flows
- Some sample component flows that are compatible with Recommendation X.229
- (Remote operations) are indicated in Figure 5/Q.774. The flows show cases of
- valid component sequences correlated to an invoked operation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. 5/Q.774 /T1113760-88 = 12 cm
-
- Figure 6/Q.774 depics that, as an extension to Recommendations X.219 and
- X.229, TCAP permits multiple return results to respond to the same Invoke
- operation for the purpose of segmenting a result over a connectionless network
- service.
- Fig. 6/Q.774 /T1113770-88 = 6 cm
-
- 3.2.1.3 Dialogue control via TC primitives
- The TC-UNI, TC-BEGIN, TC-CONTINUE and TC-END request primitives are used
- by a TC-user to control the transfer of components. Components in a message are
- delivered to the remote TC-user in the same order in which they are received by
- the originating component sub-layer from the local TC-user. The corresponding
- indication primitives are employed by the component sub-layer to inform the
- TC-user at the receiving end of the state of the dialogue.
- A TC-user employs a dialogue control request primitive to trigger
- transmission of all previously passed components with the same dialogue
- identifier. A component sub-layer dialogue control primitive in turn triggers a
- corresponding service request to the transaction sub-layer, the sub-layer where
- the transaction control service is provided. A mapping of TC to TR transaction
- control primitives is provided in Table 3/Q.774.
- TABLE 3/Q.774
- Mapping of TC Dialogue Handling Service Primitives to TR Primitives
-
- TC Primitive TR Primitive
- TC-UNI TR-UNI
- TC-BEGIN TR-BEGIN
- TC-CONTINUE TR-CONTINUE
- TC-END TR-END
- TC-U-ABORT TR-U-ABORT
- TC-P-ABORT TR-P-ABORT
- Dialogue begin
- A TC-BEGIN request primitive results in a TR-BEGIN request primitive,
- which begins a transaction, and transmits any (0 or more) components passed on
- the interface with the same dialogue ID.
- At the destination end, a TR-BEGIN indication primitive is received by the
- component sub-layer. It causes a TC-BEGIN indication primitive starting a
- dialogue to be delivered to the TC-user, followed by component handling
- primitives associated with each of the components received (if any).
- Dialogue continuation
- A TC-CONTINUE request primitive results in a TR-CONTINUE request primitive
- which transmits any components passed on the interface with the same dialogue ID.
- If reject components (see S 3.2.2.2) have been built by the component sub-layer
- for this dialogue, they are also transmitted.
- At the destination end, a TR-CONTINUE indication received by the component
- sub-layer causes a TC-CONTINUE to be delivered to the TC-user, followed by
- component handling primitives associated with each of the components received.
- Dialogue end
- In the case of basic end of a dialogue, any components passed on the
- interface plus any reject components built by the component sub-layer for this
- dialogue are passed for transmission to the transaction sub-layer in a TR-END
- request primitive, then the dialogue is ended.
- At the destination end, a dialogue ends when each component (if any)
- accompanying the TR-END indication primitive have been delivered to the TC-user
- by an appropriate component handling primitive following the TC-END indication.
- The component sub-layer does not check, when a TC-user requests the end of
- a dialogue, that all the component state machines associated with this dialogue
- have returned to Idle. Similarly, no check is made by the component sub-layer
- that all the state machines associated with a dialogue have returned to Idle when
- it has delivered the components accompanying a TR-END indication primitive. In an
- end situation, any non-idle-state machine is returned to Idle when the TR-END
- request primitive is passed to the transaction sub-layer (at the originating
- side), or when all accompanying components have been delivered to the TC-user at
- the destination side; any components pending transmission are discarded.
- Prearranged end and TC-user abort of a dialogue do not trigger
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- transmission of pending components. All state machines associated with the
- dialogue are returned to idle, and the components are discarded.
- 3.2.2 Abnormal procedures
- 3.2.2.1 Dialogue control
- Any abnormal situation detected by the component sub-layer results in the
- rejection of a component, and in notification to the local TC-user. The component
- sub-layer never decides to abort a dialogue. Abort of a dialogue is always the
- reflection of a decision by:
- - the transaction sub-layer to abort the underlying transaction. The
- component sub-layer idles the operation state machines of the dialogue,
- discards any pending component, and passes an abort indication to the
- TC-users (TC-P-ABORT indication primitive);
- - the TC-user to abort the dialogue. At the originating side, a
- TC-U-ABORT request is received from the TC-user: active component state
- machines for this dialogue are idled, and a TR-U-ABORT request is
- passed to the transaction sub-layer. At the destination side, a
- corresponding TR-U-ABORT indication is received from the transaction
- sub-layer, any active component state machines for the dialogue are
- idled, and a TC-U-ABORT indication is passed to the TC-user;
- In both cases, accompanying information (P-Abort cause, or user-provided
- information) passes transparently through the component sub-layer.
- Handling of the notification of abnormal situations which cannot be
- related to a particular dialogue is for further study.
- 3.2.2.2 Abnormal procedures relating to operations
- The following abnormal situations are considered:
- - no reaction to class 1 operation invocation (see S 3.2.1.1.3);
- - receipt of a malformed component: the component type and/or the Invoke
- ID cannot be recognized (i.e. the state machine cannot be identified);
- - receipt of a well-formed component in violation of authorized state
- transitions.
- The actions taken by the component sub-layer to report component portion
- errors are shown in Table 4/Q.774. The following considerations have guided the
- choices indicated in this Table:
- - When a protocol error has been detected by the local TC-user, this
- TC-user is not subsequently advised via the TC-Reject (as indicated in
- Table 4/Q.774) since it is already aware of the protocol error.
- - In other cases (reject by component sub-layer), the local TC-user is
- always advised so that it can issue a dialogue control primitive (see
- the reject mechanism described below).
- - When a component is rejected, the associated state machine returns to
- Idle.
- - The reject mechanism applies whenever possible: even if the Invoke ID
- is not assigned or not recognized (i.e. no state machine can be
- identified), the reject mechanism should be initiated. The only case
- where rejection is purely local is when the component to be rejected is
- itself a reject component.
- Protocol errors in the component portion of a TCAP message are reported
- using the Reject component. The Reject component is sent in response to an
- incorrect component other than Reject.
- When an invoke ID is available in a component to be Rejected, this ID is
- reflected in the Reject component.
- TABLE 4/Q.774
- Action Taken on Protocol Errors in Component Portion
-
- Local Remote
- C Type of Local Component Local Component Remote
- o error action State user state user
- m Machine advised machine advised
- p
- o
- n
- e
- n
- t
- T
- y
- p
- e
- r
- e
- c
- e
- i
- v
- e
- d
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
-
- I
- N
- V
- O
- K
- E
- Linked ID Init. Inv: NA Yes a) Inv: Yes
-
-
- RSyntax Init. Return Yes a) NA Yes
- Eerror Reject to Idle
- T
- U
- R
- N
- -
- R
- E
- S
- U
- L
- T
- (
- L
- /
- N
- L
- )
- o
- r
- RInvoke ID Init. NA Yes a) NA Yes
- Eunassigned Reject
- T
- U
- R
- N
- -
- E
- R
- R
- O
- R
- ROperation Init.
- EClass 2/4
- T
- U
- R
- N
- -
- R
- E
- S
- U
- L
- T
- (
- L
- /
- N
- L
- )
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
-
-
- ROperation Init. Return to Yes a) NA Yes
- EClass 3/4 Reject Idle
- T
- U
- R
- N
- -
- E
- R
- R
- O
- R
- RSyntax Local Return to Yes NA No
- EError Reject NA b)
- J
- E
- C
- T
- UInvoke ID Init. No Change Yes a) Return to Yes
- Nderivable Reject (NA) Idle
- K
- N
- O
- W
- N
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- NA: Not applicable.
- a) This is to alert the TC User so it can issue a dialogue control primitive to send the
- Reject component formulated by the Component Sub-Layer.
- b) If Invoke ID present, and Invoke Problem, return Component State machine to idle.
- Component type abbreviations are identified in Table 1/Q.774.
- In the case of multiple components within a message, when a malformed
- component is detected by the component sub-layer, subsequent components in the
- message are discarded.
- Rejection of any portion of a segmented result shall be equivalent to
- rejecting the entire result.
- The associated state machine is returned to idle. Subsequent portions of
- the same segmented result shall also be rejected on the basis of no active state
- machine.
- The reject mechanism: when the component sub-layer detects a situation
- where (non-local) reject should be initiated (as per Table 4/Q.774), it builds a
- reject component, stores it, and informs the local TC-user by means of
- TC-L-REJECT indication primitive. The TC-user may decide:
- a) to continue the dialogue, or
- b) to end the dialogue using the basic scenario, or
- c) to abort the dialogue.
- In cases a) and b), the first dialogue handling primitive (TC-CONTINUE
- request or TC-END request respectively) issued by the TC-user triggers
- transmission of the stored reject component(s) built for this dialogue by the
- component sub-layer. The remote component sub-layer receives the reject
- component(s) built for this dialogue, idles the corresponding component state
- machine(s) if possible (as per Table 4/Q.774) and informs the TC-user of the
- (remote) rejection via TC-R-REJECT information primitive(s).
- If the component sub-layer generated reject combined with accumulated
- components from the TC-user exceeds the message length limitations, then the
- TC-user, being aware of the reject component, must initiate two dialogue handling
- primitives. The component sub-layer, also being aware of the length problem, will
- send all the components, except the reject, with the first primitive. The reject
- will be sent with the next dialogue handling primitive together with any further
- components provided by the TC-user.
- 3.3 Transaction sub-layer procedures
- 3.3.1 General
- The transaction sub-layer provides for an association between its users
- (TR-users). This association is called a transaction.
- The transaction sub-layer procedure associates each TCAP message and,
- therefore, all the contained components with a particular transaction.
- The transaction sub-layer processes the transaction portion (message type
- and transaction ID) of a TCAP message. Transaction IDs identify a transaction.
- Each end assigns a local transaction identification; local transaction IDs are
- exchanged in the transaction portion of messages as indicated in Q.773.
- The component portion of a TCAP message is passed between the component
- sub-layer and the transaction sub-layer as user data in the transaction sub-layer
- primitives.
- 3.3.2 Mapping of TR service primitives to message types
- Recommendation Q.771 describes the services performed by the transaction
- sub-layer by defining the service interface between the TR user and the
- transaction sub-layer and the transaction sub-layer and the SCCP. Similarly,
- state transition diagrams appear in Recommendation Q.771 based on service
- primitives. In this section, a message based description of the protocol is
- provided. A mapping of TR-primitives to transaction sub-layer protocol data units
- is indicated in Table 5/Q.774.
- TABLE 5/Q.774
- Mapping of TR Service Primitives to Messages
-
- Service Primitive Message Type
- TR-UNI Unidirectional
- TR-P-ABORT Abort
- TR-BEGIN Begin
- TR-CONTINUE Continue
- TR-U-ABORT Abort
- TR-END End
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- 3.3.3 Normal procedures
- 3.3.3.1 Message transfer without establishing a transaction
- 3.3.3.1.1 Actions of the sending end
- The TR-UNI request primitive is used when a TR-user sends a message to
- another TR-user but does not need to enter into a transaction. A unidirectional
- message, which does not have a transaction ID, is used in this case.
- 3.3.3.1.2 Actions of the receiving end
- The receipt of a unidirectional message causes a TR-UNI indication
- primitive to be passed to the TR-user. No further action is taken by the
- transaction sub-layer.
- 3.3.3.2 Message transfer within a transaction
- 3.3.3.2.1 Transaction begin
- In the following discussion, the sending node of the first TCAP message is
- labelled node "A", and the receiving node is labelled node "B".
- 3.3.3.2.1.1 Actions of the initiating end
- The TR-user at node "A" initiates a transaction by using a TR-BEGIN
- request primitive, which causes a begin message to be sent from node "A" to node
- "B".
- The begin message contains an originating transaction ID. This transaction
- ID value, when included in any future message from node "A" as the originating
- transaction ID or in a message to node "A" as the destination transaction ID,
- identifies the transaction to node "A".
- Once the transaction sub-layer at node "A" has sent a begin message it
- cannot send another message to the transaction sub-layer at node "B" for the same
- transaction until it receives a continue message from node "B" for this
- transaction.
- 3.3.3.2.1.2 Actions of the receiving end
- be
- be passed to the TRVuser at node SBT. In response to a TRVBEGIN indication
- primitive, the TRVuser at node SBT decides whether or not to establish a
- transaction. If the TRVuser does want to establish a transaction, it passes a
- TRVCONTINUE request primitive to the transaction subVlayer; otherwise, it
- terminates the transaction (see ' 3.3.3.2.3). These conditions are defined by the
- TRVuser.
- The Begin message contains only an originating transaction ID. If, after
- receiving a Begin message with a given originating transaction ID, the
- transaction subVlayer receives another Begin message with the same originating
- transaction ID, the transaction subVlayer does not consider this as an abnormal
- situation: a second transaction is initiated at node SBT.
- 3.3.3.2.2 Transaction continuation
- A Continue message is sent from one node to another when a TRVCONTINUE
- request primitive is passed from the TRVuser to the transaction subVlayer at the
- sending node.
- A Continue message includes the destination transaction ID which is
- identical to the originating transaction ID received in messages from the peer
- node. Each node assigns its own originating transaction ID at transaction
- initiation time. The transaction IDs remain constant for the life of the
- transaction.
- A Continue message includes both an originating transaction ID and a
- destination transaction ID. The originating transaction ID, in successive
- continue messages is not examined.
- Receipt of a Continue message causes a TRVCONTINUE indication primitive to
- be passed to the destination TRVuser.
- Once the user at node SBT has responded with a TRVCONTINUE request
- primitive to establish a transaction, all subsequent interactions at either end
- between the TRVuser and the transaction subVlayer are via TRVCONTINUE primitives
- until the transaction is to be terminated. In message terms, once a Continue
- message is sent from node SBT, all subsequent messages shall be Continue messages
- until the transaction is to be terminated.
- 3.3.3.2.3 Transaction termination
- The basic method: A TRVuser at either end may terminate a transaction by
- passing a TRVEND request primitive (indicating basic end) to the transaction
- subVlayer. An end message is sent to the peer entity which, in turn, passes a
- TRVEND indication promitive to its TRVuser. The end message contains a
- destination transaction ID.
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- The preVarranged method: This method implies that the peer entities know a
- priori V at a given point in the application script V that the transaction will
- be released. In this case, the TRVuser passes a TRVEND request primitive
- (indicating preVarranged end) to its transaction subVlayer, and no End message is
- sent.
- 3.3.3.2.4 Abort by the TRVuser
- When a TRVuser wants to abort a transaction, it passes a TRVUVABORT
- request primitive to the transaction subVlayer, which sends an abort message with
- userVprovided (cause and diagnostic) information.
- At the receiving side, the transaction subVlayer receiving an Abort
- message containing userVprovided information passes this information without
- analyzing it to the TRVuser in a TRVUVABORT indication primitive.
- 3.3.3.2.5 Example of message exchange
- two
- two TRVusers.
- Fig. 7/Q.774 /T1106500-87 = 8 cm
-
- 3.3.3.2.6 Transaction state transition diagrams
- A state machine is associated with a transaction at each end of this
- transaction. Four transaction states are introduced:
- V Idle: no state machine exists;
- V Init Sent (IS): a Begin message has been sent; an indication from the
- peer entity whether the transaction has been established or not is
- awaited;
- V Init Received (IR): a Begin message has been received; a request from
- the TRVuser either to continue the transaction, or to terminate it, is
- awaited;
- V Active: the transaction is established: continue messages can be
- exchanged in both directions simultaneously.
- Figure 8/Q.774 shows the transaction state transition diagram.
- 3.3.4 Abnormal procedures relating to transaction control
- The following abnormal situations are covered by the transaction
- subVlayer:
- 1) no reaction to transaction initiation;
- 2) receipt of an indication of abnormal situation from the underlying
- layer;
- 3) receipt of a message with an unassigned or nonVderivable destination
- transaction ID (nonVderivable means that the information is not found
- or not recognized): the message cannot be associated with a
- transaction;
- 4) receipt of a message with a recognized destination transaction ID: the
- message can be associated with a transaction, but the message type is
- not compatible with the transaction state.
- Fig. 8/Q.774 /T1113780-88 = 12 cm
-
- Case 1 is covered by a local, implementationVdependent, mechanism which
- results in aborting the transaction locally, as described below.
- Case 2 is for further study.
- When a transaction portion error is found (cases 3 and 4 above), the
- transaction subVlayer should take the following actions.
- The status of the originating transaction ID should be checked. Actions
- are the following:
- tr
- transaction; or,
- 2) If the originating transaction ID is derivable, the following actions
- are taken:
- i) The transaction subVlayer should form an abort message with an
- appropriate PVAbort cause and transmit it to the originating end.
- The originating end will then take the appropriate action to
- terminate the transaction if the originating transaction ID is
- assigned.
- ii) If the destination transaction ID is not derivable or derivable but
- not assigned, the transaction subVlayer takes no action to
- terminate the transaction at its end.
- iii) If the destination transaction ID is derivable and assigned:
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- a) the transaction subVlayer terminates the transaction at its end,
- i.e. return to idle;
- b) the transaction subVlayer informs the component subVlayer of the
- abort of the transaction via the transaction subVlayer abort;
- and
- c) the component subVlayer should:
- V release all component IDs associated with this transaction,
- V discard any pending components for that transaction,
- V inform the TCVuser of the transaction abort.
- Finally, regardless of the disposition of the transaction IDs, the entire
- erroneous TCAP message should be discarded.
- TABLE 6/Q.774
- Actions when an Abnormal Transaction Portion is Received
-
- Local End (detects protocol error) Remote End
- MOrigin. Destin. Action Transacti Local Transact User
- eTr. Id. Tr. Id. on State User ion Advised
- s Mach. Advised State
- s Mach.
- a
- g
- e
- T
- y
- p
- e
- R
- e
- c
- e
- i
- v
- e
- d
- U - - Discard - c) No - c) No
- N
- I
- D
- I
- R
- E
- C-
- T
- I
- O
- N
- A
- L
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
-
- B der. - Abort NA No Ret to Yes a)
- E Idle a)
- G
- I
- N
-
-
-
- C unass. Idle a)
- O
- N
- T
- I
- N
- U
- E
- der. ass. Abort Ret to Yes Ret to
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
-
-
-
- E unass.
- N
- D
- /
- A
- B
- O
- R
- T
-
-
-
-
- U unass.
- N
- K
- N
- O
- W
- N
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
-
-
-
- NA: Transition to the Idle state is Not Applicable b)
- not der.: not derivable.
- der.: derivable.
- ass.: derivable and assigned.
- unass.: derivable but unassigned.
- a) If the Transaction ID is assigned at this end, otherwise the state transition is
- not applicable, and the user is not informed.
- b) The expression NA is used in those cases where the normal procedure of Return to
- Idle at both ends following the appearance of an abnormal situation is Not Applicable
- because it is impossible to identify the Transaction ID(s) and therefore to relate the
- damaged message to a specific transaction at either ends (Local and/or Remote end).
- c) The Unidirectional message does not refer to an explicit transaction and therefore
- it does not affect the Transaction State Machine.
- When receiving an Abort message, the destination transaction sub-layer
- does the following:
- - if the Abort message contains user-abort information (or no
- information), inform the TR-user by means of the TR-U-ABORT indication
- primitive;
- - if the Abort message contains a P-Abort cause information, inform the
- TR-user by means of the TR-P-ABORT indication primitive. Notification
- to the management is for further study;
- - in both cases, discard any pending messages for that transaction and
- return the transaction state machine to Idle.
- 4 Transaction capabilities based on a connection oriented network service
- For further study.
- ANNEX A
- (to Recommendation Q.774)
- Transaction capabilities SDLs
- A.1 General
- This Annex contains the description of the transaction capability
- procedures described in Recommendation Q.774 by means of SDLs according to the
- CCITT specification and description language. In order to facilitate the
- functional description as well as the understanding of the behaviour of the
- signalling system, the transaction capabilities application part (TCAP) is
- divided into the component sub-layer and the transaction sub-layer (Figure
- A-1/Q.774). The component sub-layer again is divided into a component handling
- block (CHA) and a dialogue handling block (DHA) (Figure A-2/Q.774).
- The SDL is provided according to this functional partitioning which is
- used only to facilitate understanding and is not intended to be adopted in a
- practical implementation of the TCAP. The functional blocks and their associated
- service primitives are shown in Figure A-2/Q.774.
- A.2 Abbreviations used in the SDL diagrams
- CSL Component sub-layer
- L Last component
- NL Not last component
- SCCP Signalling connection control part
- TC Transaction capabilities
- TCAP Transaction capabilities application part
- TCU TC-user
- TSL Transaction sub-layer
- ISP Intermediate service part
- IS Initiation sent state
- IR Initiation received state
- DHA Dialogue handling
- CHA Component handling
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- RJ Reject
- RE Return error
- RR Return result
- INV Invoke
- ISM Invocation state machine
- CCO Component coordinator
- UNI Unidirectional
- A.3 Drafting conventions
- To indicate the direction of each interaction the symbols are used as
- shown below:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig, /T1120540-88. = 8 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. A-1/Q.774 /T1120550-88 = 13 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. A-2a/Q.774 /T1120560-88 = 18 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. A-2b/Q.774 /T1120570-88 = 13 .5cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. A-3/Q.774 /T1120580-88 = 19 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. A-3/Q.774 (sheet 2 of 6) /T1120590-88 = 16.5 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. A-3/Q.774 (sheet 3 of 6) /T1120600-88 = 20 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. A-3/Q.774 (sheet 4 of 6) /T1120610-88 = 17 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. A-3/Q.774 (sheet 5 of 6) /T1120620-88 = 13 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. A-3/Q.774 (sheet 6 of 6) /T1120630-88 = 23 cm
-
-
- Fig. A-4/Q.774 (sheet 1 of 2) /T1120640-88 = 2.5 cm
-
-
- Fig. A-4/Q.774 (sheet 2 of 2) /T1120650-88 = 17 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. A-5/Q.774 (sheet 1 of 4) /T1120660-88 = 25 cm
-
-
- Fig. A-5/Q.774 (sheet 2 of 4) /T1120670-88 = 25.5 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. A-5/Q.774 (sheet 3 of 4) /T1120680-88 = 21.5 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. A-5/Q.774 (sheet 4 of 4) /T1120690-88 =19 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. A-6/Q.774 (sheet 1 of 6) /T1120670-88 = 13 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. A-6/Q.774 (sheet 2 of 6) /T1120710-88 = 18 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. A-6/Q.774 (sheet 3 of 6) /T1120720-88 = 11.5 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. A-6/Q.774 (sheet 4 of 6) /T1120730-88 = 17.5 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
- Fig. A-6/Q.774 (sheet 5 of 6) /T1120740-88 = 16.5 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VI.9 - Rec. Q.774 PAGE77
-
- Fig. A-6/Q.774 (sheet 6 of 6) /T1120750-88 = 15 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE60 Fascicle VI.9 - Q.774
-
-